На злобу дня

Опыт внедрения 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 года.

Комментарии посетителей сайта