Брандмауэр Symfony2 занимает много времени

У меня проблема с компонентом брандмауэра Symfony2, который уходит на некоторые запросы.

Я заметил, что это происходит, главным образом, во время запросов AJAX и очень специфических – когда я ищу объект, использующий LIKE% ..% заявлений в доктрине (не уверен, что это важно, но это то, что я заметил;)).

Вызов одного и того же URL-адреса чуть позже (1 или 2 с) приводит к «нормальному» времени обработки брандмауэра.

Я не использую внешние источники данных для аутентификации, все хранится в PostgreSQL.

Посмотрите следующий график:

временная шкала http://img.ruphp.com/php/Zrzut ekranu 2012-11-19 o 18.26.11.png

Есть ли способ напрямую отладить брандмауэр?

Моя конфигурация выглядит так:

security: firewalls: admin_area: provider: db_users pattern: ^/admin anonymous: ~ form_login: login_path: /admin/login check_path: /admin/login-check logout: path: /admin/logout target: /admin switch_user: { role: ROLE_SUPERADMIN, parameter: _become_user } secured_area: pattern: ~ anonymous: ~ http_basic: realm: "Secured Demo Area" access_control: - { path: ^/admin/clip-manager/clip/encode/*, roles: IS_AUTHENTICATED_ANONYMOUSLY, ip: 127.0.0.1 } - { path: ^/admin/login, roles: IS_AUTHENTICATED_ANONYMOUSLY } - { path: ^/admin/login-check, roles: IS_AUTHENTICATED_ANONYMOUSLY } - { path: ^/admin, roles: [ROLE_ADMIN_LOGIN, ADMIN_AREA] } providers: db_users: entity: { class: Webility\Bundle\AppUserBundle\Entity\User, property: username } encoders: Webility\Bundle\AppUserBundle\Entity\User: algorithm: sha256 iterations: 3 encode_as_base64: false acl: connection: default

Я использую Symfony\SecurityBundle и JMSSecurityExtraBundle .

Как добавить настраиваемое исключение в symfony2 Микроядро Symfony 3 и ORM Вызов функции-члена addPaiementType () на null использование usort с ассоциативным массивом внутри контроллера symfony2 Развертывание приложения Symfony2 с Capifony - загрузчик APC по-прежнему использует предыдущий выпуск

У меня была такая же проблема и я хочу поделиться с вами ребятами.

Увеличение времени ответа сервера

Проблема, вызванная Symfony \ Component \ Security \ Http \ Firewall ~ 107406 ms

Сроки применения

Решение;

В нашем случае проблема была обработкой сеанса, которую мы использовали в файле php.ini.

Предыдущая конфигурация;

 session.save_handler = files

Новая конфигурация;

 ;session.save_handler = files session.save_handler = memcached session.save_path = "127.0.0.1:11212"

Я изменил обработчик сеанса на memcached. Поскольку я уже использую memcached, мне нужен второй экземпляр memcached или, поскольку я реализовал дополнительный порт, прослушанный memcached, решил эту проблему;

Чтобы запустить memcached для прослушивания двух портов, я редактирую memcached.conf

Предыдущая конфигурация;

 -p 11211 -l 127.0.0.1

Новая конфигурация

 #-p 11211 #-l 127.0.0.1 -l 127.0.0.1:11211 -l 127.0.0.1:11212

и просто перезапустив экземпляр memcached, memcached начал прослушивать два порта в одном экземпляре.

 service memcached restart

Чтобы проверить, что memcached прослушивает и отвечает на новые порты, вы можете запустить команду telnet;

 telnet 127.0.0.1 11211 telnet 127.0.0.1 11212

ожидаемый результат;

 Trying 127.0.0.1... Connected to 127.0.0.1. Escape character is '^]'.

Результат очень быстрый;

Конечная шкала приложений

Надеюсь, это решение поможет вам.

Попробуйте использовать другой обработчик сеанса. У меня была такая же проблема в моей коробке бродяг. Не знаете, что вызвало это. Подробнее см. http://ctors.net/2014/04/21/symfony_slow_in_vagrant .

Это довольно необычное поведение (если вы не делаете что-то, ну … необычное;).

Попробуйте использовать один из профилировщиков PHP, чтобы узнать, что происходит. Я могу порекомендовать XHProf с графическим интерфейсом XHProf . Его легко настроить и использовать.

Я просто догадываюсь, но проблема может быть связана с запросом базы данных, о котором вы говорили. Проверьте, установлены ли поля, используемые в запросе, соответствующие индексы.

Изменить: я случайно наткнулся на эту статью, связанную с блоком Symfony: http://12wiki.blogspot.com.es/2012/11/why-does-symfony-2-firewall-take-so.html

Кажется, это проблема DNS.