Кэширование байт-кода с помощью 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 = [ 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:

Подробности о параметрах конфигурации здесь: 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

Теперь создадим MD5 хэш пароля и отредактируем наш xcache.ini (или php.ini ) b и перезапустим сервер:

$ echo -n "secreatpassword" | md5sum - $ 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 ххх. ххх. ххх. ххх

ВНИМАНИЕ! Значит статистика панели администратора, как собственно и само кэширование байт-кода, не является глобальной, а распространяется исключительно на каждый виртуальный хост (домен) в отдельности.

Если панель администратора не доступна из пакетов, то её можно "выдрать" из архива с исходным кодов (директория 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


АдМинь БагоИскатель ярый борец за безглючную работу любых механизмов и организмов во всей вселенной и потому пребывает в вечном поиске всяческих багов, а тот кто ищет как известно всегда находит. Когда что-то или кого-то вылечить не в состоянии, то со словами "Я в аду, а вы все черти" уходит в запой выйдя из которого снова берётся лечить неизлечимое.


Как известно, PHP - интерпретируемый язык, т.е. каждый раз при обращении к скрипту, этот скрипт компилируется. Если у вас 1 скрипт, то ничего страшного нет, так как время компиляции не большое. Но в современных CMS и фрэймворках при отображении страницы используется 10-300 отдельных php-файлов (проще говоря, инклуды). Чем больше инклудов и чем они тяжелее, тем дольше выполняется процесс компиляции.

Для решения этой проблемы придумали хранить компилированный вид скрипта в памяти. Существуют специальные модули для хранения откомпиленного кода в памяти. Называются они акселераторы.

Самые известные: eAccelerator, APC, XCache. У каждого есть свои плюсы и минусы. Я использую XCache как наиболее быстрый и надежный. Хотя у каждого есть свое мнение по поводу надежности.

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

Админка XCache

У XCache есть небольшая админка для вывода статистики и сброса кэша. Лежит она обычно здесь /usr/local/share/examples/xcache/admin/. Поэтому нужно вынести эту папку куда-нибудь в корень сайта или в свою админку, чтобы можно было смотреть из браузера. Можете скачать админку .

Вот так это выглядит у меня

Первая таблица показывает общую статистику. В ней 2 строчки, так как процессор у меня 2-х ядерный и XCache распределяет кэш по обоим ядрам. Всего у меня выделено 512M.

Админка может выдавать ошибку Fatal error: xcache_count(): xcache.admin.user and xcache.admin.pass
Значит у вас включена авторизация в конфиге xCache.
Проще всего ее вырубить. Я на своем сервере один и ставить пароли внутри сервера мне не нужно.
Авторизация выключаетя в конфиге xcache.admin.enable_auth = Off

Конфиг xCache лежит обычно по адресу /etc/php5/conf.d/xcache.ini
После редактирования конфига необходимо перезагрузить Апач.

Статистика xCache

вернемся к админке (см. картинку выше).

Slots - кол-во слотов под кэш. Это я так понимаю на сколько частей бьется выделяемая память. В моем случае это 8000. Чем больше это значение, тем быстрее идет поиск, но требуется больше памяти.

Size - размер памяти под XCache

Avail - сколько памяти осталось. Как видно у меня ее не осталось. Забиты все 512 Mb

Clear - кнопка сброса кэша

Hits - сколько обращений к файлам было сделано

Misses - сколько обращений к файлам было сделано, но этих файлов в памяти не оказалось. Это нормальный процесс. Файлы меняются - из кэша они вылетают. Но в моем случае все файлы просто не влезают в память, поэтому их там нет, и соответственно идут промахи.

Clogs - это я так понимаю сколько раз мы обратились за какими-то файлами в кэш, но в это время эти файлы еще компилировались, т.е. была блокировка.

OOMs - сколько раз файлы не попали в кэш из-за нехватки памяти.

Cached - кол-во файлов в кэше. Всего у меня 6400 файлов.

Настройки xCache

Пара слов о том, сколько памяти следует выделять. Изначально я выделил 128 Mb, но эта память забилась за 10 минут. Поэтому я выделил 512 Mb и этот объем уже забился за 1 час. Казалось бы, можно выделить 1 Gb и тогда бы точно всё влезло. Но памяти всего 4Гб и лучше выделить ее под MySQL (об этом ). Тем более, файлы которые не попали в кэш в течение часа - это редко используемые скрипты. Просто есть сайты, на которые заходят 10-100 человек в день и без кэширования там можно обойтись. Это так называемый «длинный хвост», который редко используется, но места занимает много. В моем случае это 3% (Misses/Hits).

Что еще не нужно забывать. Допустим, вы поменяли какой-то код на крупной проекте. Место в памяти освободилось и на это пустое место могут быть записаны файлы низкопосещаемых проектов. Соответственно файлы крупного проекта не попадут в кэш. Проще говоря, XCache НЕ умеет отслеживать какие файлы можно выкинуть из кэша и поместить на их место более часто запрашиваемые файлы (это так называемый «горячий» кэш). Поэтому нужно сбрасывать кэш вручную через админку.

Нижняя таблица показывает какие файлы кэшируются и насколько эффективно.

Hits - кол-во обращений к этому скрипту в памяти. Чем больше - тем лучше. Если для некоторых файлов долгое время это значение меньше 10, то значит этот файл редко используется, и лишь занимает место в памяти.

Size - размер этого файла в памяти. Вот тут самое интересное. Получается, что откомпилированный файл занимает в памяти в 10 раз больше места, чем на диске. OMG!

SrcSize - размер файла на диске

Access - как давно обращались к этому файлу

Create - сколько времени этот файл лежит в кэше

Мой конфиг
xcache.size = 512M
xcache.count = 2
xcache.slots = 8K
xcache.ttl = 0
xcache.gc_interval = 0
xcache.var_size = 0M
xcache.var_count = 2
xcache.var_slots = 8K
xcache.var_ttl = 0
xcache.var_maxttl = 0
xcache.test = Off
xcache.cacher = On
xcache.stat = On

Как видно, я отключил использование XCache в качестве кэширования результатов вычислений (xcache.var_size = 0M). Для этого у меня есть Memcache.

Ну и собственно результаты: ускорение в 2-3 раза. Если раньше страница генерировалась за 0.3 секунды (с учетом Memcache), то теперь 0.1 секунды. Это пример из одного проекта на CMS LiveStreet.

Для ускорения выполнения php скриптов существуют так называемые акселераторы.Суть их в том, что один раз вызванных php скрипт компилируется и попадает в кеш акселератора. После чего при повторном обращении к скрипту он уже отдается в откомпилированном виде. Что очень сильно сказывается на нагрузке на сервер, так как теперь не нужно каждый раз компилировать заново скрипт.

xCache - очень хороший, на мой взгляд, акселератор PHP, который увеличивает скорость выполнения php скриптов в нескольку раз..

Использование акселератора в несколько раз уменьшает время генерации страницы, а так же уменьшает нагрузку на процессор сервера. Так у меня после настройки Xcache на сервере количество используемого процессорного времени уменьшилось практически в двое. А так как я использую для размещения своих сайтов виртуальный сервер, где плачу только за использование ресурсов, использование php-акселератора уменьшает итоговою стоимость аренды сервера.

Итак приступим к установке на сервер акселератор php кода — Xcache .

Я использую на сервере операционную систему Ubuntu 10.04 , но и на более новых, например недавно вышедшей Ubuntu LTS 12.04 14.04 с долговременной поддержкой, все будет выглядеть так же. Так же все работает на Debian 7.

Устанавливаем:

Sudo apt-get install php5-xcache Установится последняя стабильная версия, по этому ничего компилировать не нужно.

После установки открываем файл конфигурации в /etc/php5/conf.d/xcache.ini

У меня он выглядит так:

Xcache.size = 128M

xcache.count = 14

xcache.slots = 8K

xcache.ttl = 36000

xcache.gc_interval = 36000

xcache.var_size = 8M

xcache.var_count = 14

xcache.var_slots = 8K

xcache.var_ttl = 36000

xcache.var_maxttl = 604800

xcache.cacher = On

xcache.stat = On

Основные параметры:

xcache.size — отвечает за количество памяти для хранения кеша. Если значение будет слишком маленьким, то эффекта от кеширования толком не будет.

xcache.count - количество блоков, на которые будет делиться кеш. Рекомендуется выставлять по количеству ядер процессора.

xcache.slots — Количество слотов под кеш, чем больше слотов, тем больше скорость поиска в кеше. Но и увеличивается потребление памяти. Рекомендуется оставлять значение по умолчанию: 8K

xcache.ttl -Время жизни кешированного объекта в секундах. Если к объекту никто не обращался в течении указанного времени, объкт помечается как не используемый, и в последующем удаляется из кеша сборщиком мусора.

xcache.gc_interval - интервал запуска сборщика мусора в секундах. Определяет промежуток времени, через который будет запускться сборщик мусора. Запустившись, он ищет записи с истекшим временем жизни(xcache.ttl) и удаляет их из кеша.

Два последних параметра(xcache.ttl и xcache.gc_interval) очень важны в настройке Xcache, но на многих сайтах значения данных параметров выставлены в 0, соответственно из кеша ничего не удаляется, и при полном заполнении новые скрипты уже в него не попадают. То есть, если вы разместите на сервере новый сайт, то его скрипты уже не попадут в кеш, так как он полностью заполнен скриптами предыдущего сайта.

Параметры начинающиеся с xcache.var_ отвечают за кэширования результатов вычислений. И их параметры аналогичны.

После сохранения настроек следует перезапустить вебсервер.

Sudo /etc/init.d/apache2 restart

Просмотр статистики Xcache

У Xcache есть своя админка, которая позволяет просматривать текущее состояние и очищать кеш.Что бы она заработала, нужно скопировать папку admin из /usr/local/share/examples/xcache/admin/ в каталог вашего сайта.(Ubuntu)

В Debian 7 данный каталог лежит по пути /usr/share/xcache

Но перед этим следует установить пароль в файле конфигурации. За это отвечают параметры

Xcache.admin.enable_auth

xcache.admin.user= «user»

xcache.admin.pass= «password»

пароль нужно указывать как md5хеш для большей надежности.

Получить md5хеш можно выполнив

Php echo md5("password"); ?> или можно получить хеш например на сайте http://mainspy.ru/shifrovanie_md5

Slots - Количество слотов под кеш, чем больше слотов, тем больше скорость поиска в кеше. Но и увеличивается потребление памяти. Рекомендуется оставлять значение по умолчанию: 8K

Size - размер памяти под Xcache.

Avail - сколько памяти осталось.

Clear - сбросить кеш.

Hits - сколько обращений к файлам было сделано

Misses - сколько обращений к файлам было сделано, но этих файлов в памяти не оказалось.

Clogs - временно заблокированных файлов в кеше.

OOMs - Количество файлов которые не смогли попасть в кеш изза нехватки памяти.

Cached - Общее количество файлов в кеше.

Нижняя таблица показывает какие файлы кэшируются и насколько эффективно.

Hits - кол-во обращений к этому скрипту в памяти. Чем больше - тем лучше. Если для некоторых файлов долгое время это значение меньше 10, то значит этот файл редко используется, и лишь занимает место в памяти.

Size - размер этого файла в памяти. Вот тут самое интересное. Получается, что откомпилированный файл занимает в памяти в 10 раз больше места, чем на диске. OMG!

SrcSize - размер файла на диске

Access - как давно обращались к этому файлу

Create - сколько времени этот файл лежит в кэше

xCache - это программа из серии тех, что кешируют байт-код php для оптимизации и ускорения выполнения скриптов. Как, например, eAccelerator или PHP-APC.

В статье будет рассматриваться базовая настройка. А дальше можно подкручивать параметры в соответствии с собственными пожеланиями.

Нет смысла долго задерживаться на установке: всё делается стандартно.

Aptitude install php5-xcache

Основные настройки кэша

Первоочередной задачей будет указание основных настроек для работы. Откройте в вашем любимом редакторе файл . Все параметры собраны по группам. В данный момент нам нужна группа

xcache.size = 32M

Данная директива указывает общий объём памяти для кэша. По-умолчанию 16 мегабайт.

xcache.count = 1

Указывается по количеству процессоров (ядер). Два ядра - ставим 2. И так далее. Или два одноядерных процессора.

xcache.ttl = 0

Время жизни кэша. Иногда может потребоваться очистка кэша через определённый промежуток времени. Значение указывается в секундах.

Рассмотрим параметры, необходимые для кэширования переменных. В определённых условиях, это тоже может пригодится.

xcache.var_size = 8M

Общий объём памяти, выделяемой для кэша переменных. По-умолчанию 0 - отключено.

xcache.var_count = 1

Эта переменная аналогична xcache.count.

xcache.var_ttl = 0

Тут тоже можно привести аналогию с переменной xcache.ttl: задаёт время жизни кэша переменных.

xcache.var_maxttl = 0

Эта переменная указывает максимальное время жизни кэша.

XCache Optimizer

Иногда может потребоваться включить встроенный в xCache оптимизатор. Для этого следующую директиву нужно перевести из состояния off в состояние on .

Xcache.optimizer = on

Админ-панель для xCache

xCache поставляется вместе с панелью управления, позволяющей просматривать статистику. У меня связка nginx+php-fpm, пример будет написан с учётом этого.

Прежде всего настраиваем nginx. Здесь потребуется использование alias для location.

Location /x/ { alias /usr/share/xcache/admin/; location ~ .php$ { fastcgi_index index.php; fastcgi_pass unix:/run/php-fpm.sock; include fastcgi_params; fastcgi_param PHP_ADMIN_VALUE "open_basedir=/usr/share/xcache/admin/:/var/php-temp-dir/"; fastcgi_param SCRIPT_FILENAME $request_filename; } }

Прописываем конфигурацию для любого виртуального хоста, перезапускаем nginx: service nginx reload . Далее в браузере открываем страницу http://example.com /x/mkpassword.php . Example.com замените на адрес вашего сайта, для которого вы создали алиас.

При помощи данного скрипта нужно создать md5-хеш пароля, который будет использоваться при аутентификации в админ-панели xCache. Достаточно указать пароль, нажать кнопку «Отправить запрос» и полученный результат скопировать.

После всех этих действий открываем файл /etc/php5/mods-available/xcache.ini , в группе редактируем необходимые параметры.

xcache.admin.user = «username»

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

xcache.admin.pass = «…»

Здесь в кавычках нужно указать md5-хеш пароля пользователя.

Сохраняем отредактированный файл и перезапускаем apache, php-cgi или php-fpm.

Теперь админка xcache должна быть доступна по адресу http://example.com/x/. Попробуйте авторизоваться и просмотреть статистику.

Каждый раз, когда вы открываете страничку динамического веб-приложения, веб-сервер обращается к PHP, который загружает запрошенный.php файл и все include и require, затем парсит их, компилирует в промежуточный байт-код (opcode ) и исполняет. Причем в больших проектах процесс включения всех include файлов может занимать весьма продолжительное время.
Поэтому были разработаны многочисленные PHP-кешеры . Наиболее популярные из них - APC (Alternative PHP Cache), XCache и eAcelerator . Все они позволяют сохранять и повторно использовать скомпилированный байт-код PHP, что позволяет экономить время на сборку всех включений и их компиляцию, экономит процессорное время и оперативную память (причем весьма значительно). Помимо этого, они позволяют хранить в кеше переменные PHP и обращаться к ним при следующем вызове скрипта. Какой из этих кешеров использовать - не особо принципиально, по производительности они не сильно отличаются. Я выбрал XCache т.к. на него никто не ругается как на eAcelerator и я уже работал с APC и было интересно попробовать что-то новое

Так вот, приступим. Установка XCache довольно простая, но тем не менее:

Устанавливаем пакет php5-xcache :

sudo apt-get install php5-xcache

Редактируем конфиг расширения PHP xcache.ini

sudo nano /etc/php5/conf.d/xcache.ini

Там исправляем строчки:

размер opcode кеша. Ставьте около 64Мб. Вообще, если у вас на сайте много различных PHP скриптов с большим количеством различных include, то нужно ставить значение побольше. Если сайт всего один - можно оставить маленькое значение.
xcache.size = 64M

размер кеша данных/переменных. Если в качестве кешера данных используете именно xCache, то ставьте побольше. Если используете Memcached, то установите 0
xcache.var_size = 32M

указываем количество процессоров (или ядер) на вашем компьютере
xcache.count = 2

Убедитесь, что есть строчка
xcache.cacher = On

Для просмотра статистики использования, оценки эффективности и управления кешем имеется веб-интерфейс администратора. В Ubuntu он устанавливается вместе с пакетом и находится в папке /usr/share/xcache в поддиректориях admin и coverage. Так что скопируйте эти папки в директорию веб-сервера, затем настройте доступ к ним в том-же xcache.ini
xcache.admin.user = "user"
xcache.admin.pass = "5f4dcc3b5aa765d61d8327deb882cf99"
;xcache.admin.pass = ""
Здесь первая опция - логин пользователя, вторая - md5 хеш пароля (можно сделать, например, ). Можно оставить пароль пустым.

Сохраняем, перезапускаем веб-сервер/php

Sudo /etc/init.d/apache2 restart

P.S.: после установки кешера отвалился Zend Debuger с сообщением " Debugger compile handler overriden, cannot continue "... Конечно странно ставить кешер и дебагер на одну тачку, но все-же.. Чтобы это пофиксить рекомендуют

sudo nano /etc/php5/conf.d/zend_debugger.ini

и там закомментировать строчку zend_debugger.expose_remotely=allowed_hosts
Эта опция

The zend_debugger.expose_remotely directive determines whether the debugger will expose itself (i.e. signal its presence) to remote clients. This is required if you want the Zend Studio Browser Toolbar to automatically detect pages that can be debugged. Select ‘always’, ‘never’, or ‘allowed_hosts’ (this only exposes the hosts in the allowed host list)

Т.е. указывает в каких случаях Zend Debuger должен выдавать свое присутствие (посредством специального HTTP заголовка).Таким образом, эта опция становится в положение ‘always’, но зато хотябы будет работать... Тем не менее, это явно баг а не фича!