У меня есть Symfony2, работающий на Ubuntu Server 12.04 (64-разрядная) VM (VirtualBox). Хост - это MacBook pro. По какой-то причине я получаю очень длинные запросы в режиме разработки (app_dev.php). Я знаю его медленнее в режиме dev, но я говорю 5-7 секунд за запрос (иногда даже медленнее). На моем Mac я получаю время запроса 200 мс или около того в режиме разработки.
После просмотра моей временной шкалы в профилировщике Symfony2 я заметил, что ~ 95% времени запроса - это "время инициализации". Что это? Какие причины могут быть такими медленными?
Эта проблема применима только к Symfony2 в режиме dev, а не к другим сайтам, которые я запускаю на виртуальной машине, и даже к Symfony2 в рабочем режиме.
Я видел это (http://stackoverflow.com/questions/11162429/whats-included-in-the-initialization-time-in-the-symfony2-web-profiler), но он, похоже, не отвечает мои вопросы.
Я выяснил причину проблемы (и ее не Symfony2). По какой-то причине на виртуальной машине ubuntu времена модификации некоторых файлов неверны (т.е. в будущем и т.д.). Когда symfony2 проверяет это время с помощью filemtime() на своем реестре, он определяет, что кеш не является более свежим, и он восстанавливает все это. Я не смог понять, почему он это делает.
У меня было 5-30 секунд ответов от Symfony2 по умолчанию. Теперь это ~ 500 мс в среде dev.
Затем я изменил следующие вещи в php.ini
:
realpath_cache_size = 4M
(или более)XDebug
полностью (тест с phpinfo
)OPcache
(или APC)И voilá, ответы прошли менее 2 секунд в режиме dev! Надеюсь, что это поможет.
До: 6779 мс
После: 1587 мс
Symfony2 читает классы из тысяч файлов и медленный процесс. При использовании небольшого кеша реального пути PHP пути к файлу должны решаться один за другим каждый раз, когда новый запрос создается в среде dev, если они не находятся в кэше реального пути PHP. По умолчанию для Symfony2 кеш realpath слишком мал. В prod это, конечно, не проблема.
Кэширование метаданных (например, сопоставление) также очень важно для дальнейшего повышения производительности:
doctrine:
orm:
entity_managers:
default:
metadata_cache_driver: apc
query_cache_driver: apc
result_cache_driver: apc
Для этого вам нужно включить APCu
. Он APC
без кэша bytecode, поскольку OPcache
уже выполняет кэширование кода операции. OPcache
встроен с PHP 5.5.
(в среде prod такой же ответ составляет ~ 80 мс)
Обратите внимание: это проект использует 30+ пакетов и содержит десятки тысяч строк кода, почти сотни собственных сервисов, поэтому 0.5s неплохо работает в локальной среде Windows, используя лишь несколько простых оптимизаций.
realpath_cache_size = 4096k
сработала для нас. Спасибо!
$loader = require_once __DIR__ . '/../app/bootstrap.php.cache'
содержит классы из всех этих тысяч файлов (поэтому я думаю, что изменение realpath_cache_size со значения по умолчанию на 4096 не имело никакого эффекта в моем случае)
Мне также необходимо отключить xdebug (v2.2.21)
для отладки загрузки apache2 max в моем macbook. Он был установлен с использованием macports:
sudo port install php54-xdebug.
При включенном xdebug на каждой странице заканчивается максимальное время загрузки, при этом фатальная ошибка превышает максимальное время ожидания отправления. Когда отключено, все просто заряжается нормально в разумное ожидаемое время. Я пришел к этому с помощью MAMP, по умолчанию отключен xdebug, а apache2 работает быстро, как обычно. Я могу изменить для другого отладчика, что питти, потому что xdebug работал отлично раньше.
Конфигурация:
У нас та же проблема. Здесь у нас есть 10 секунд и более для каждого запроса. Я вижу, если я удаляю следующие строки в bootstrap.php.cache, все времена возвращаются в нормальном состоянии (298 мс).
foreach ($meta as $resource) {
if (!$resource->isFresh($time)) {
return false;
}
}
Возможно, у нас неправильные изменения, но мы не знаем, как их исправить. Кто-нибудь знает решение?
Вы можете перемещать APP/var/cache
в /dev/shm/YourAppName/var/cache
. Но хорошо иметь встроенный контейнер в локальных файлах также для автозаполнения IDE и проверки кода. В app/AppKernel.php
:
public function getCacheDir()
{
return $this->getVarOrShmDir('cache/' . $this->getEnvironment());
}
public function getLogDir()
{
return $this->getVarOrShmDir('logs');
}
private function getVarOrShmDir($dir)
{
$result = dirname(__DIR__) . '/var/' . $dir;
if (
in_array($this->environment, ['dev', 'test'], true) &&
empty($_GET['warmup']) && // to force using real directory add ?warmup=1 to URL
is_dir($result) && // first time create real directory, later use shm
file_exists('/bin/mount') && shell_exec('mount | grep vboxsf') // only for VirtualBox
) {
$result = '/dev/shm/' . 'YourAppName' . '/' . $dir . '/' . $this->getEnvironment();
}
return $result;
}
Как сказано в https://stackoverflow.com/questions/12905404/symfony2-slow-initialization-time, причиной такого поведения могут быть настройки Ubuntu VM. Вы должны синхронизировать дату и время между хостом и гостевой ОС, как описано в https://superuser.com/questions/463106/virtualbox-how-to-sync-host-and-guest-time.
Дата изменения файла изменяется на значение хоста при загрузке файла в виртуальную машину через FTP. Поэтому, почему filemtime() возвращает неправильное значение.
У меня также были проблемы с медленными загрузками страниц в разработке, которые могут очень расстраивать, когда вы настраиваете CSS или что-то подобное.
После небольшого копания я обнаружил, что для меня проблема была вызвана Assetic, которая перекомпилировала все активы при каждой загрузке страницы:
Отключив использование контроллера Assetic, я смог резко увеличить нагрузку на страницу. Однако, как сказано выше, это связано с затратами на восстановление ваших активов всякий раз, когда вы делаете им изменения (или устанавливаете на них часы).
Я отключил xdebug, и это привело к уменьшению времени загрузки с 17s (да...) до 0,5 с.
В app_dev все кеши и автоматическая загрузка начинаются с нуля, и то, что я обнаружил в dev более медленным, - это orm. Я уклоняюсь от использования orm и фокусируюсь главным образом на dbal из-за этого, хотя я, вероятно, не должен. Orm используется совсем немного в sf2. Мое предположение - это то, что замедляет вас в dev. Посмотрите на разницу между конфигурацией вашего dev и prod. Однако некоторые настройки вашего конфигуратора dev могут сделать разработку намного более приятной и приятной. Просто попробуйте и осознайте, что вы делаете. например, выключение контроллера ветки, а затем изменение большого количества шаблонов будет расстраивать. Ваша потребность в очистке кеша. Но, как вы уже упоминали, его разработчик только и когда придет время жить, symfony ускорится для вас.