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

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

График профилирования

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

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

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

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

security.yaml
routing.yaml
Astrups / SpectacleBundle / Entity / User.php
Astrups / SpectacleBundle / Услуги / Sha1Salted.php

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

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

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

Увы, оказалось, что 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";

Выход был:

  Соединение приняло 230.18503189087 мс
 Запрос занял 64.532995223999 мс

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

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

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

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