Symfony2 Медленное время инициализации

Ответ 1

Я выяснил причину проблемы (и ее не Symfony2). По какой-то причине на виртуальной машине ubuntu времена модификации некоторых файлов неверны (т.е. в будущем и т.д.). Когда symfony2 проверяет это время с помощью filemtime() на своем реестре, он определяет, что кеш не является более свежим, и он восстанавливает все это. Я не смог понять, почему он это делает.

Ответ 2

У меня было 5-30 секунд ответов от Symfony2 по умолчанию. Теперь это ~ 500 мс в среде dev.

Затем я изменил следующие вещи в php.ini:

• set realpath_cache_size = 4M (или более)
• отключен XDebug полностью (тест с phpinfo)
• realpath_cache_ttl = 7200
• включен и правильно установлен OPcache (или APC)
• перезапустил Apache, чтобы перезагрузить php.ini

И 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.

---- После: 467 ms ----

(в среде prod такой же ответ составляет ~ 80 мс)

Обратите внимание: это проект использует 30+ пакетов и содержит десятки тысяч строк кода, почти сотни собственных сервисов, поэтому 0.5s неплохо работает в локальной среде Windows, используя лишь несколько простых оптимизаций.

Ответ 3

Мне также необходимо отключить xdebug (v2.2.21) для отладки загрузки apache2 max в моем macbook. Он был установлен с использованием macports:

sudo port install php54-xdebug.

При включенном xdebug на каждой странице заканчивается максимальное время загрузки, при этом фатальная ошибка превышает максимальное время ожидания отправления. Когда отключено, все просто заряжается нормально в разумное ожидаемое время. Я пришел к этому с помощью MAMP, по умолчанию отключен xdebug, а apache2 работает быстро, как обычно. Я могу изменить для другого отладчика, что питти, потому что xdebug работал отлично раньше.

Конфигурация:

• MacOSX 10.6.8
• macports 2.1.3
• Apache 2.2.24
• php 5.4

Ответ 4

У нас та же проблема. Здесь у нас есть 10 секунд и более для каждого запроса. Я вижу, если я удаляю следующие строки в bootstrap.php.cache, все времена возвращаются в нормальном состоянии (298 мс).

foreach ($meta as $resource) { 
if (!$resource->isFresh($time)) {
return false;
}
}

Возможно, у нас неправильные изменения, но мы не знаем, как их исправить. Кто-нибудь знает решение?

Ответ 5

Как сказано в fooobar.com/questions/110280/..., причиной такого поведения могут быть настройки Ubuntu VM. Вы должны синхронизировать дату и время между хостом и гостевой ОС, как описано в https://superuser.com/questions/463106/virtualbox-how-to-sync-host-and-guest-time.

Дата изменения файла изменяется на значение хоста при загрузке файла в виртуальную машину через FTP. Поэтому, почему filemtime() возвращает неправильное значение.

Ответ 6

Вы можете перемещать 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;
}

Ответ 7

Я отключил xdebug, и это привело к уменьшению времени загрузки с 17s (да...) до 0,5 с.

Ответ 8

У меня также были проблемы с медленными загрузками страниц в разработке, которые могут очень расстраивать, когда вы настраиваете CSS или что-то подобное.

После небольшого копания я обнаружил, что для меня проблема была вызвана Assetic, которая перекомпилировала все активы при каждой загрузке страницы:

http://symfony.com/doc/current/cookbook/assetic/asset_management.html#dumping-asset-files-in-the-dev-environment

Отключив использование контроллера Assetic, я смог резко увеличить нагрузку на страницу. Однако, как сказано выше, это связано с затратами на восстановление ваших активов всякий раз, когда вы делаете им изменения (или устанавливаете на них часы).

Ответ 9

В app_dev все кеши и автоматическая загрузка начинаются с нуля, и то, что я обнаружил в dev более медленным, - это orm. Я уклоняюсь от использования orm и фокусируюсь главным образом на dbal из-за этого, хотя я, вероятно, не должен. Orm используется совсем немного в sf2. Мое предположение - это то, что замедляет вас в dev. Посмотрите на разницу между конфигурацией вашего dev и prod. Однако некоторые настройки вашего конфигуратора dev могут сделать разработку намного более приятной и приятной. Просто попробуйте и осознайте, что вы делаете. например, выключение контроллера ветки, а затем изменение большого количества шаблонов будет расстраивать. Ваша потребность в очистке кеша. Но, как вы уже упоминали, его разработчик только и когда придет время жить, symfony ускорится для вас.