TraceableFirewallListener的加载时间非常长 [英] TraceableFirewallListener extremely long loading time

问题描述

在我的一个symfony项目中，最近我一直遇到巨大的性能问题，其中的性能问题似乎位于"Symfony \ Bundle \ SecurityBundle \ Debug \ TraceableFirewallListener"的后面，恰好在"Symfony \ Component \ Security \ Http \ Firewall \ ContextListener".

in one of my symfony projects I've been running into huge performance issues lately, where the performance issue seems to lay behind "Symfony\Bundle\SecurityBundle\Debug\TraceableFirewallListener", precisely in the "Symfony\Component\Security\Http\Firewall\ContextListener".

下面是我的开发服务器和实时服务器的屏幕截图-服务器规格符合要求，并且我绝对确定问题不会出在服务器后面，因为其他项目在类似的服务器上运行得很好.

Below are screenshots from my development server and the live server - server specifications are meeting the requirements and I'm absolutely sure the issue does not lie behind the server, as other projects have been running great on similiar servers.

我很乐意为您提供任何有关如何进一步解决或调试此问题的提示. Symfony版本是4.0.1，更新到最新版本并不能解决问题.

I would appreciate any hint as to how to troubleshoot or debug this problem further, as I'm at my wits end. Symfony version is 4.0.1, updating to the latest version did not resolve the issue.

使用秒表组件进一步调试使我得出结论，加载时间来自Symfony/Bridge/Doctrine/Security/User/EntityUserProvider，方法"refreshUser"，行93，调用"$ refreshedUser = $ repository-> find($ id);"最大的一部分是2681ms中的2647ms.不过，我不知道从现在开始该去哪里.

Debugging a little further using the stopwatch component lead me to the conclusion that the loading times are coming from Symfony/Bridge/Doctrine/Security/User/EntityUserProvider, method "refreshUser", line 93, call "$refreshedUser = $repository->find($id);" for the biggest part, as in 2647ms out of 2681ms. I have no clue where to go from now on, though.

开发

实时

我的安全性配置:

security:
# https://symfony.com/doc/current/security.html#where-do-users-come-from-user-providers
encoders:
    App\Entity\User:
        algorithm: bcrypt
    legacy_encoder:
        algorithm: md5
        encode_as_base64: false
        iterations: 1

providers:
    in_memory: { memory: ~ }
    db_provider:
        entity:
            class: App\Entity\User
            property: username

role_hierarchy:
    ROLE_USER_MO: ROLE_USER
    ROLE_USER_WKB: ROLE_USER

firewalls:
    dev:
        pattern: ^/(_(profiler|wdt)|css|images|js)/
        security: false
    main:
        #pattern: ^/
        #http_basic: ~

        anonymous: ~
        provider: db_provider

        user_checker: App\Security\UserChecker

        logout:
            path: /logout
            target: /login

        form_login:
            login_path: login
            check_path: login

access_control:
    #- { path: ^/, roles: ROLE_USER }
    #- { path: ^/login, allow_if: "is_anonymous() and !is_authenticated()" }
    - { path: ^/motivwelten, roles: ROLE_USER }
    - { path: ^/services/.*, roles: ROLE_USER }
    - { path: ^/shop, roles: ROLE_USER }
    - { path: ^/shop/.*, roles: ROLE_USER }
    - { path: ^/user/.*, roles: ROLE_USER }
    - { path: ^/password-forgotten, allow_if: "is_anonymous() and !is_authenticated()" }
    - { path: ^/password-forgotten/.*, allow_if: "is_anonymous() and !is_authenticated()" }
    - { path: ^/downloads, roles: ROLE_USER }

erase_credentials: false

推荐答案

在3月1日进行我的编辑之后，我将提供为我确定加载时间的解决方案".我认为这不能称为问题的解决方案，因为我操纵了框架的核心代码，这可能永远都不做或没有必要.

Following up on my edit on Mar 1, I'll provie the "solution" that fixed the loading times for me. I don't think this can be called a solution to the problem, as I manipulated the core code of the framework, which should probably never be done or necessary.

我可以肯定，问题出在我过去建立的实体结构中，用户实体中有几个fetch=EAGER部分，应尽可能避免.

I am fairly certain the problem lies in the entity structure I've built over the time, where there are several fetch=EAGER parts in the user entity, which should be avoided where possible.

我从以下位置更改了Symfony/Bridge/Doctrine/Security/User/EntityUserProvider中的第93行

I changed the line 93 in Symfony/Bridge/Doctrine/Security/User/EntityUserProvider from

$refreshedUser = $repository->find($id);

到

$refreshedUser = $repository->find(['id' => $id]);

这分别将开发人员和实时人员的加载时间从25秒减少到〜50ms，将加载时间从2.5秒减少到〜100ms.

This reduced the loading time from 25 seconds to ~50ms and from 2.5 seconds to ~100ms on dev and live respectively.

这篇关于TraceableFirewallListener的加载时间非常长的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！