Что брандмауэр Symfony делает так долго?

51

Моя страница Symfony не слишком медленная (она загружается примерно через 400 мс), но, учитывая тот факт, что это просто простая всемирная страница приветствия с базовой аутентификацией, она должна быть загружена менее чем за 100 мс. Когда я вхожу в профилировщик, я вижу следующее:

Изображение 629

Обратите внимание, что это просто говорит "Брандмауэр" за 250 мс. Я думал, что брандмауэр был просто ответственен за то, что пользователи не попали в определенные области страницы - я не могу себе представить, что это займет не более нескольких миллисекунд плюс время, необходимое для получения пользовательской информации из базы данных (которая в этом случае 61 мс).

Может кто-нибудь объяснить, что на самом деле делает брандмауэр? Если у вас есть общие указатели о том, как повысить производительность брандмауэра, это будет очень полезно.


Примечание. У меня это, конечно, есть в Googled, и я хочу указать фронт, что я подключаюсь к базе данных MySQL по IP-адресу, а не по имени хоста. Это казалось проблемой для всех остальных случаев медленного брандмауэра Symfony, который я мог найти.


Некоторые ресурсы из моего проекта, которые могут иметь значение:

  • 1
    Я предполагаю, что выполнение всех правил в security.yml, разделы провайдеров, контроля доступа и брандмауэров могут быть довольно неприятными, проверка всех этих запросов для каждого запроса занимает много времени.
  • 0
    @ xr09: 251 мс действительно очень много времени (в компьютерное время). Я не вижу способа просто прочитать кэшированную конфигурацию и применить ее к контексту безопасности, это может занять какое-то время.
Показать ещё 16 комментариев
Теги:
symfony-2.2

3 ответа

8
Лучший ответ

Увы, оказалось, что Rawdreeg отчасти прав. Я сделал 20 строк PHP скрипт, чтобы узнать, сколько времени требуется для подключения к моему серверу MySQL:

<?php

$time = microtime(true);

$con = new PDO(...);

$connect_time = microtime(true);

$result = $con->query('SHOW TABLES');

$query_time = microtime(true);

var_dump($result->fetchAll(PDO::FETCH_ASSOC));

$time_con = ($connect_time - $time) * 1000;
$time_query = ($query_time - $connect_time) * 1000;

echo "Connection took $time_con ms\n";
echo "Query took $time_query ms\n";

Выход был:

Connection took 230.18503189087 ms
Query took 64.532995223999 ms

Заполняет пробелы профилировщика Symfony. Хорошей новостью является то, что, когда мое приложение будет работать в прямом эфире, оно будет подключаться к серверу MySQL локально через сокет, поэтому он, вероятно, быстро вспыхнет! Я мало что могу сказать о скорости во время разработки, кроме как зеркалировать сервер MySQL локально.

Итак, чтобы обобщить ответ; брандмауэр Symfony изначально создает соединение с базой данных MySQL, и в моем случае это соединение происходит довольно медленно. Время соединения с MySQL составляет более 80% времени профилированного брандмауэра в моем случае.


Примечание: Я уже подключаюсь к серверу MySQL по IP-адресу, и я добавил skip-name-resolve в конфигурацию MySQL безрезультатно.

  • 0
    У меня есть приложение, которое не настроено на использование базы данных, та же проблема. Я не думаю, что это фактическая причина.
  • 0
    @guice Это было в моем случае.
8

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

После 15 минут исследований я закончил выяснять, что это было связано к конструктору PHP PDO (мой брандмауэр первым подключился к поскольку я использую Entities как пользователи). С учетом этих знаний проблема был довольно быстро найден ([1], [2]): как он оказывается используя DNS-имя (например, "localhost" ) вместо IP (например, '127.0.0.1') вызывает эту проблему.

Простое редактирование файла parameters.yml(изменение localhost на 127.0.0.1) сделал трюк сокращения времени загрузки брандмауэра до минимума.

  • 0
    Для вашей информации, лучше включить сюда основные части ответа и предоставить ссылку для справки. Поскольку целевой ресурс не гарантированно будет жив в будущем.
  • 6
    Я четко указал в своем вопросе, что это не проблема. Проверьте Примечание: часть.
Показать ещё 1 комментарий
0

Может возникнуть проблема с вашим сервером MySQL. Попробуйте добавить skip-name-resolve в раздел [mysqld] вашего файла my.cnf. Это заставляет MySQL выполнять обратный поиск DNS на IP-адрес входящих соединений.

  • 0
    Спасибо за предложение, я проверю это. Но разве соединение с MySQL не пойдет под «Доктриной» в профилировщике?
  • 0
    Я не знаю. Я просто использовал цитату в ответе Rawdreeg, которая подразумевает, что компонент брандмауэра открывает соединение с базой данных.
Показать ещё 1 комментарий

Ещё вопросы

Сообщество Overcoder
Наверх
Меню