![]() ![]() |
На злобу дняОпыт внедрения OPcache
7 лет я использовал в качестве ускорителя PHP-кода расширение eAccelerator (ea). Периодически я мониторил, что предлагают альтернативные проекты (APC, XCache), но оставался приверженцем ea. Сделал несколько патчей к этому ускорителю, которые повывашали стабильность работы в реалиях работы хостинга (отложенное кеширование недавно измененных файлов, автоматическое отключение кеширования и рестарт в случае краха во время выполнения опкода, совместимость с анонимными функциями). С выходом новой версии 1С-Битрикс обнаружилась новая проблема. 1С-Битрикс стал довольно прожорлив до памяти и сайты стали не вписываться в предусмотренные тарифными планами значения memory_limit. Но это это полбеды. В добавок оказалось, что PHP 5.3 и 5.4 иногда может делать Segmentation fault при достижении этого лимита (подтверждением этому багрепорты от пользователей PHP; к сожалению, разработчики PHP пока не решили эту проблему). И это еще не все. Иногда при достижении memory_limit стали появляться "залипшие" коннекты к базе данных MySQL (они находились в состоянии "Sleep"). Анализируя лог убивания залипших коннектов, обнаружил запрос к одному сайту, который гарантированно вызывал залипание коннекта. После отключения ea залипания не происходили. Это стало последним аргументом в пользу того, что пора попробовать альтернативный кешер. OPcache отличается от других кешеров тем, что именно он стал частью PHP с версии 5.5 (разрабатываемая версия). Для PHP 5.2, 5.3, 5.4 кешер подключается как PECL-расширение zendopcache. Миграция на OPcache вызвала затруднение в части написания файла с исключениями opcache.blacklist_filename. В ea можно указать: eaccelerator.filter = "!*/bitrix/cache/* !*/bitrix/managed_cache/* !*/bitrix/stack_cache/* *.php" Оказалось, что в OPcache * не подразумевает символ /, т.е. маска работала внутри одного каталога. В процессе изучения исходного кода выяснилось, что авторы используют возможности расширения ereg PHP: при инициализации расширение компилирует паттерны регулярных выражений-исключений, а во время работы делается только выполнение регулярных выражений по каждому скрипту-кандидату на кеширование. Очень рационально с точки зрения быстродействия (в ea этот момент примитивнее). Выяснилось, что перед компиляцей патернов ** заменяются на .*, а это уже похоже на настоящие регулярные выражения. В итоге аналогичные исключения в OPcache выглядят так: /**/bitrix/cache/ /**/bitrix/managed_cache/ /**/bitrix/stack_cache/ Слэш в начале строк нужен, чтобы OPcache не "нормализовал" путь. Разобравшись с этим нюансом, можно сделать следующие настройки в php.ini: zend_extension=/usr/local/lib/php/20100525/opcache.so opcache.memory_consumption=400 opcache.interned_strings_buffer=4 opcache.max_accelerated_files=10000 opcache.revalidate_freq=0 opcache.fast_shutdown=1 opcache.blacklist_filename=/usr/local/php5/opcache.bx.bl opcache.force_restart_timeout=60 opcache.file_update_protection=10 opcache.restrict_api=/usr/local/www/domains/1/WWW/ea/ Первые четыре параметра нужно подбирать в соответствии с количеством кешируемых файлов. opcache.memory_consumption — размер разделяемой памяти в мегабайтах. Для сред разработки в документации рекомендуется opcache.revalidate_freq сделать равным 0. Для 1С-Битрикс тоже нужен 0. Не используем "слепой" кеш, постоянно сверяем дату изменения файла. Параметр opcache.force_restart_timeout нужен, чтобы кешер автоматически перезапустился в случае проблем (например, при работе с разделяемой памятью теоретически можно словить дедлок, в ea пришлось писать патч, а тут это есть из "коробки"). Параметр opcache.file_update_protection тоже пригодится, чтобы не кешировать файлы, которые изменились меньше 10 секунд назад. OPcache не имеет встроенного менеджера кеша. Когда скрипт изменяется, его старая копия остается в памяти (wasted memory). Кеш очищается автоматически и полностью, если недостаточно доступной памяти для кеширования новых файлов и при этом количество "wasted memory" больше, чем opcache.max_wasted_percentage % от opcache.memory_consumption. По умолчанию opcache.max_wasted_percentage=5. Описание параметров можно посмотреть на сайте php.net или на официальной странице на GitHub. В итоге в "попугаях" монитора производительности 1С-Битрикс обнаружен прирост производительности примерно на 60% (с 64 до 103 баллов). Интересно было также посмотреть на реальном проекте под хорошей нагрузкой. К счастью под рукой был такой (порядка 75 тысяч хитов к PHP в час). Рост производительности составил 20-30% по сравнению с той же конфигурацией с ea без какой-либо правки кода! Опубликовано: 11 февраля 2014 года. Комментарии посетителей сайта
|
|
© Алексей Кощеев, г.Киров, 2001-2023 |
|