TraceableFirewallListener чрезвычайно долгое время загрузки

в одном из моих проектов Symfony в последнее время я столкнулся с огромными проблемами производительности, где проблема с производительностью, похоже, лежит за "Symfony\Bundle\SecurityBundle\Debug\TraceableFirewallListener", именно в "Symfony\Component\Security\Http\Firewall \Контекстный прослушиватель".

Ниже приведены скриншоты с моего сервера разработки и живого сервера — спецификации сервера соответствуют требованиям, и я абсолютно уверен, что проблема не в сервере, поскольку другие проекты отлично работают на подобных серверах.

Я был бы признателен за любую подсказку о том, как устранить неполадки или отладить эту проблему, поскольку я в своем уме. Версия Symfony — 4.0.1, обновление до последней версии не решило проблему.

Редактировать: Дальнейшая отладка с использованием компонента секундомера привела меня к выводу, что время загрузки исходит из Symfony/Bridge/Doctrine/Security/User/EntityUserProvider, метод «refreshUser», строка 93, вызов «$refreshedUser = $repository-> найти($идентификатор);" по большей части, как 2647 мс из 2681 мс. Я понятия не имею, куда идти с этого момента.

ДевTraceableFirewallListener чрезвычайно долгое время загрузкиTraceableFirewallListener чрезвычайно долгое время загрузки

РеальныйTraceableFirewallListener чрезвычайно долгое время загрузкиTraceableFirewallListener чрезвычайно долгое время загрузки

Моя конфигурация безопасности:

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
Стоит ли изучать PHP в 2026-2027 годах?
Стоит ли изучать PHP в 2026-2027 годах?
Привет всем, сегодня я хочу высказать свои соображения по поводу вопроса, который я уже много раз получал в своем сообществе: "Стоит ли изучать PHP в...
Symfony Station Communiqué - 7 июля 2023 г
Symfony Station Communiqué - 7 июля 2023 г
Это коммюнике первоначально появилось на Symfony Station .
Symfony Station Communiqué - 17 февраля 2023 г
Symfony Station Communiqué - 17 февраля 2023 г
Это коммюнике первоначально появилось на Symfony Station , вашем источнике передовых новостей Symfony, PHP и кибербезопасности.
Управление ответами api для исключений на Symfony с помощью KernelEvents
Управление ответами api для исключений на Symfony с помощью KernelEvents
Много раз при создании api нам нужно возвращать клиентам разные ответы в зависимости от возникшего исключения.
1
0
2 272
2
Перейти к ответу Данный вопрос помечен как решенный

Ответы 2

Ответ принят как подходящий

После моего редактирования от 1 марта я предоставлю «решение», которое исправило время загрузки для меня. Я не думаю, что это можно назвать решением проблемы, так как я манипулировал основным кодом фреймворка, что, вероятно, никогда не должно быть сделано или необходимо.

Я совершенно уверен, что проблема заключается в структуре объекта, которую я построил за это время, где в пользовательском объекте есть несколько частей fetch=EAGER, которых следует избегать, где это возможно.

Я изменил строку 93 в Symfony/Bridge/Doctrine/Security/User/EntityUserProvider с

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

к

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

Это сократило время загрузки с 25 секунд до ~ 50 мс и с 2,5 секунд до ~ 100 мс на dev и live соответственно.

Я решил эту проблему, изменив порядок пакетов в yourproject/config/bundles.php.

я не уверен, как появляется эта проблема. но я случайно обнаружил это средство, поставив сначала пакеты symfony и sensio.

не рекомендую менять порядок комплектов.

редактировать: извините, я проверил, и проблема в моем случае была в порядке пакетов доктрины.

Другие вопросы по теме