2016-11-17 9 views
0

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

Это займет слишком много времени, чтобы загрузить (не все время, но большую часть), и когда я смотрю профилировщик, всегда есть один «виноватый компонент»: это может быть брандмауэр, контроллер, прослушиватель профиля, ответ ядра ... является временем выполнения нескольких секунд (иногда более 10).

example case example case 2

Чтение в разных потоках я попытался установить дб как FIX IP (в случае, если это проблема поиска DNS), измененными некоторые параметры в php.ini, но ничего не изменилось. Это происходит как в моем локальном, так и в удаленном окружении, где он имеет даже ускорение PHP и OPCache.

Я не делаю ничего особенного в моем коде, даже я получаю длительное время в «привет мир» страниц, это немного расстраивает :)

+0

Вы используете его в Windows (как известно, медленно)?Вы читали http://stackoverflow.com/questions/25405360/symfony-2-performance-optimisations?rq=1? – Veve

+1

, что действительно сложно сказать - в какой ОС вы работаете, в какой версии PHP вы используете Symfony как dev или prod, работаете ли вы с Symfony со встроенным сервером cli php или на реальном веб-сервере (apache, nginx)? ваш кеш должен прогреться перед каждым запросом ...? как настроено ваше ведение журнала? включена ли дополнительная отладка? – LBA

+0

Thx ко всем да, я забыл упомянуть, что он работает на windows :(, и realpath_cache_size вызывается проблемой! – yauros

ответ

1

ли вы xdebug расширение включена в php.ini?

Если это так, попробуйте отключить его, особенно в производственной среде.

+0

привет, thx для ответа отключен как на локальном, так и на удаленном – yauros

+0

Отметьте это сообщение, это может помочь вам: http://www.stackoverflow.com/questions/13459157/symfony2-firewall-takes-ages/40618145#40618145 – progg

+0

Thx to everyone at в конце было значение realpath_cache_size. Теперь выглядит нормально! – yauros

6

Это происходит потому, что у symfony есть тысячи файлов для чтения, прежде чем начать печатать «Hello world». На самом деле ваши жесткие диски оказывают наибольшее влияние на эффективность Symfony. К счастью, есть несколько простых шагов для достижения удовлетворительного уровня.

  1. php.ini:
    установить эти два параметра на гораздо более высоких значений, чем по умолчанию, т.е.
    realpath_cache_size = 4096k
    realpath_cache_ttl = 7200
  2. свалка композитор автозагрузка:
    composer dump-autoload --optimize - это создает файл дампа с загруженными классов
  3. Я не знаю, как вы используете opcache, но я рекомендую вам установить модуль apcu. После этого кэша использование метаданных в Symfony config_prod.yml:
     
    doctrine: 
    orm: 
        metadata_cache_driver: apc 
        result_cache_driver: apc 
    
  4. Веб/app.php должен выглядеть иметь некоторые дополнительные линии по сравнению с регулярным одного:

    use Symfony\Component\HttpFoundation\Request; 
    use Symfony\Component\ClassLoader\ApcClassLoader; 
    
    $loader = require __DIR__.'/../app/autoload.php'; 
    include_once __DIR__.'/../app/bootstrap.php.cache'; 
    
    $apcLoader = new ApcClassLoader(md5($_SERVER['HTTP_HOST']), $loader); 
    $loader->unregister(); 
    $apcLoader->register(true); 
    
    require_once __DIR__.'/../app/AppCache.php'; 
    $kernel = new AppKernel('prod', false); 
    $kernel->loadClassCache(); 
    $kernel = new AppCache($kernel); 
    Request::enableHttpMethodParameterOverride(); 
    $request = Request::createFromGlobals(); 
    $response = $kernel->handle($request); 
    $response->send(); 
    $kernel->terminate($request, $response); 
    

Другое, но также очень важно:

  1. Использовать PHP 7, который имеет значительное повышение эффективности,
  2. Использовать PHP с FPM (FastCGI Proces Manager)
  3. Не использовать SQL-решение для кеширования запросов, то есть Redis, Elasticsearch
  4. Отключить xdebug - убедитесь, что профайлер не показывает, что вы его используете.

Список длинный на самом деле, но первые 4 пункта плюс 8-й из них делают трюк в большинстве распространенных случаев. Надеюсь, это поможет.

+0

Нужно ли очищать кеш APC, если я использую 'metadata_cache_driver: apc' или стандартный кэш приложений/консолей php: clear --env = prod --no-debug? – StockBreak

+0

Если APCu предоставляется php.ini, тогда вы должны очищать его каждый раз, когда вы меняете PHP-файл (или TWIG, который также обрабатывается PHP). Я использую этот инструмент для очистки кеша APC: https://gordalina.github.io/cachetool/ –