Кэширование байт-кода с помощью PHP акселераторов существенно увеличивает производительность и отклик сервера на запросы клиентов. Существует несколько популярных PHP акселераторов, среди которых наш выбор пал на XCache.
Большинству известно, что PHP работает по принцыпу транслирующего интерпретатора, - т.е. сначала выполняется синтаксический анализ скрипта, потом его содержимое транслируется в байт-код (http://ru.wikipedia.org/wiki/Байткод), а уже затем интерпретируется и выдаётся результат.
PHP акселераторы на определённое время кэшируют однажды созданый байт-код для последующего его многоразового использования в том случае если исходный крипт не был подвержен изменениям. Таким образом PHP избавляется от 2-х этапов работы: синтаксический анализ скрипта и его трансляция в байткод - при наличии кэшированного байткода PHP остаётся его только интерпретировать и отдать результат. А тот факт, что байт-код хранится/кэшируется в оперативной памяти, даёт довольно ощутимый прирост производительности.
Для PHP есть ещё несколько популярных акселераторов, APC (Latest beta version: 3.1.13 (2012-09-03)) и eAccelerator (Latest stable version: 0.9.6.1 (2010-05-31)), которые считаются потенциально-мёртвыми, а следовательно их использование крайне не рекомендуется. Например для eAccelerator хоть и заявлена поддержка РНР 5.4, но было замечены неоднократные глюки при его использовании и выражались они, кажись, в ошибке НТТР 500 на некоторых веб-страницах, которые работали отлично после отключения eAccelerator.
На сегодняшний день XCache самый идеальный кандидат, который поддерживает все версии РНР включая РНР 5.6.
List of PHP accelerators - Wikipedia, the free encyclopedia: http://en.wikipedia.org/wiki/List_of_PHP_accelerators
Установка и начальная конфигурация XCache в Linux
Установить XCache в Linux можно из пакетов:
$ yum install php-xcache xcache-admin $ apt-get install php5-xcache
xcache.ttl и xcache.var_maxttl по умолчанию = 0, т.е. срок жизни кэша неограничен, что на наш взгляд не есть гуд имхо скрипты могут быть уже удалены, а кэш зависнет занимая такую нужную всем РАМу. Поэтому установим срок жизни кэша на сутки (86400 сек.), с интервалом сбора мусора "*gc_interval" в 3600 сек. (один час):
$ vi /etc/php.d/xcache.ini [xcache-common] extension = xcache.so [xcache.admin] xcache.admin.enable_auth = Off xcache.admin.user = "admin" xcache.admin.pass = "3cb1cc80547422c9ef667953f00e9a17" [xcache] xcache.shm_scheme = "mmap" xcache.size = 60M xcache.count = 1 xcache.slots = 8K xcache.ttl = 86400 xcache.gc_interval = 3600 xcache.var_size = 4M xcache.var_count = 1 xcache.var_slots = 8K xcache.var_ttl = 0 xcache.var_maxttl = 86400 xcache.var_gc_interval = 3600 xcache.var_namespace_mode = 0 xcache.var_namespace = "" xcache.readonly_protection = Off xcache.mmap_path = "/tmp/xcache" xcache.coredump_directory = "" xcache.coredump_type = 0 xcache.disable_on_crash = Off xcache.experimental = Off xcache.cacher = On xcache.stat = On xcache.optimizer = Off [xcache.coverager] xcache.coverager = Off xcache.coverager_autostart = On xcache.coveragedump_directory = "" $ service httpd restart
Проверить успешно ли установлен XCache можно php скриптом, в результатах работы которого должны присутствовать строки с параметрами конфигурации XCache:
<?php phpinfo(); ?>
Подробности о параметрах конфигурации здесь: http://xcache.lighttpd.net/wiki/XcacheIni#INIsettingsforXCache
Установка XCache Admin Panel
Панель администратора XCache полезна на начальной стадии, когда не мешало бы выяснить эффективность использования кэша и хватает ли под него отведённой РАМы (оперативной памяти), а после этого панель админа может быть удалена на многие лета.
Панель админа XCache представляет из себя простой набор PHP скриптов и если был установлен пакет xcache-admin, то эти самые PHP скрипты административной панели будут доступны по адресу /usr/share/xcache, которые можно либо скопировать в нужный нам веб-каталог (cp -r /usr/share/xcache /var/www/html/), а лучше просто создать алиас для нужного нам виртуального хоста:
<virtualhost ...> ... Alias /xcacheadmin "/usr/share/xcache/" <Directory "/usr/share/xcache/"> Options Indexes MultiViews FollowSymLinks AllowOverride All Order allow,deny Allow from all </Directory> </virtualhost>
Теперь создадим MD5 хэш пароля и отредактируем наш xcache.ini (или php.ini) b и перезапустим сервер:
$ echo -n "secreatpassword" | md5sum 3cb1cc80547422c9ef667953f00e9a17 - $ vi /etc/php.d/xcache.ini [xcache.admin] xcache.admin.enable_auth = On xcache.admin.user = "admin" xcache.admin.pass = "3cb1cc80547422c9ef667953f00e9a17" $ /etc/init.d/httpd restart
Теперь панель администратора XCache должна быть доступна по адресу http://my-host.com/xcacheadmin. Вот только в моём случае авторизация оказалась неудачной и XCache Admin Panel постоянно вторила "Authentication Failed".
По некоторым данным (#339 (xache3.1.0 Repeat pop-up window requires authentication) – XCache) проблема связана с тем, что до бакэнда не доходит HTTP_AUTHORIZATION. Кому-то вроди помогает .htaccess со строкой "SetEnvIf Authorization .+ HTTP_AUTHORIZATION=$0", но было решено "забить" на все эти проблемы и полностью отключить "xcache.admin.enable_auth = Off" эту инвалидную XCache авторизацию и использовать её прямо из того же .htaccess:
AuthUserFile "/path/to/.htpasswd" AuthName "Administrator only" AuthType Basic require valid-user Satisfy all #Order allow,deny #Allow from ххх.ххх.ххх.ххх
Таким образом Basic авторизация работает прекрасно, следовательно проблема не в связке серверов, а скорее всего в самой панели XCache Admin.
ВНИМАНИЕ! Значит статистика панели администратора, как собственно и само кэширование байт-кода, не является глобальной, а распространяется исключительно на каждый виртуальный хост (домен) в отдельности.
Если панель администратора не доступна из пакетов, то её можно "выдрать" из архива с исходным кодов (директория httpd), подробнее по ссылкам:
- InstallAdministration – XCache
- http://xcache.lighttpd.net/wiki/InstallAdministration
- http://xcache.lighttpd.net/wiki/GettingSource
XCache удаляет кэш каждые 10 минут
Если на протяжении xcache.ttl времени жизни кэша, в статистике использования закешированного байткода количество хитов (Hits) не увеличивается, а размер доступной (свободной, Avail) оперативной памяти не уменьшается или же эти показатели регулярно (через 5-10 мин.) обнуляются, то значит что-то нужно подшаманить с настройками.
Кэш XCache сбрасывается после каждой перезагрузки сервера (reload, graceful or restart). Некоторые индивиды вместо тонкой и расчетливой настройки сервера просто оставляют конфиги по умолчанию, а с регулярными утечками памяти и падениями сервера борются командой apachectl graceful выполняемой по крону. Поэтому, сначала нужно проверить крон-задачи на наличие команд перезапускающих веб-сервер.
Если в кроне ничего подозрительного, тогда нужно копнуть под конфигурацию сервера и особенно если скрипты на нём работают ака FastCGI:
$ vi /etc/httpd/conf.d/fcgid.conf # FcgidProcessLifeTime 3600 FcgidProcessLifeTime 0 # default: FcgidIdleTimeout 300 FcgidIdleTimeout 86400 # Default: FcgidMaxRequestsPerProcess 0 # must by <= PHP_FCGI_MAX_REQUESTS FcgidMaxRequestsPerProcess 0 ... DefaultInitEnv PHP_FCGI_CHILDREN 1
Выше приведена рабочая конфигурация, где время жизни и максимальное число запросов для Fcgid процессов не проверяется (т.е. = 0), за исключением проверки ожидающих процессов, а именно если процесс ожидающий запроса не получит такового в течении FcgidIdleTimeout (24 часов.), то он будет убит и XCache соответственно сброшен.
Проблема с регулярным сбросом кэша всплыла когда некоторые пользователи выбирали способ хранения сессий с помощью XCache, а поскольку процессы Fcgid с настройками по умолчанию регулярно прибивались вместе с кэшем XCache, то пользователям снова приходилось выполнять авторизацию раз за разом.
Список оф. релизов XCache: http://xcache.lighttpd.net/wiki/ReleaseArchive
