Что-то вроде предисловия
Написал я эту заметку примерно два года назад и умерла она вместе со старым дневником. Повторно разместить её я взялся потому, что на удивление проблема до сих пор жива раз даже на хабре и на stackoverflow люди жалуются, что не смогли её победить. Удивляюсь лени разработчиков xcache не опубликовавших в документации описание такой важной особенности модуля. Заметка была немного переработана и обновлена.

Да, так же должен сказать, что от xcache я в итоге отказался по ряду причин (в частности из-за агрессивного кэширования) в пользу APC. Ну а теперь сама заметка...

Интрига

Установил я на днях на сервере для php оптимизатор xcache, чтобы не только код разогнать, но и попользоваться быстрым key-value хранилищем. И казалось бы, чего уж проще, скачал, подключил, пару строчек в конфиг черкнул — готово. Но не тут-то было… Когда я начал эксперементы с key-value хранилищем начали сыпаться ошибки:

xcache.var_size is either 0 or too small to enable var data caching

И при этом любые попытки поработать с хранилищем проваливались с треском...

Перерыл на сколько возможно интернет, зачитал до дыр сайт разработчиков xcache: ни крошки информации. Везде на форумах, сайтах люди пишут одно и то же «выскакивает данная ошибка, что делать?» и вразумительных ответов нет. Та что там вразумительных — их просто нет. Что ж... Становится интереснее. Поскольку С/С++ для меня второй язык после русского, то я решил залезть в исходники xcache и поглядеть «а какого собсно говоря чёрта?». Ответ на удивление нашёл очень быстро. В очередной раз удивился почему об этом на сайте xcache ни слова.

Кульминация

А выяснил я следующее. Нашёлся кусок кода который проверяет в каком режиме работает php — как fastcgi или как cli (обычная консоль). Если php работает в cli режиме (в моём случае я запускал php-cli), то выполняется следующий код:

xcache.size = xcache.size_var = 0;

т. е. хранилище с кэшем отрубается вовсе. А затем, где-то в глубинах кода, когда происходит попытка записать что-то в хранилище, делается проверка на его размер, и если он равен нулю (наш случай), то нас приветствует весёлая надпись «xcache.var_size is either 0 or too small to enable var data caching». =) А вот если php запустить в fast-cgi режиме, то всё работает как надо: и кэш и хранилище. Так же по коду я выяснил как обойти это отключение в cli режиме: если в xcache.ini установить параметр xcache.test = On, то кэш с хранилищем будут работать всегда, даже в cli версии. Вот такой вот хитрый расклад.

Если вы получаете такую ошибку при работе php с apache или другим веб сервером у вашего хостера, то видимо у него связка php—web server явно сконфигурирована не как fast-cgi и php работает в cli режиме со всеми вытекающими отсюда бедами. Между прочим это самый плохой и медленный метод сопряжения веб сервера и php (Ave хостерам, выводы делайте сами). Но если у вас это свой личный сервер и нет желания что-либо менять переходя на fast-cgi, то ставьте xcache.test = On и всё должно заработать. Однако тут есть подводные камни. Не бегите сейчас на радостях включать тестовый режим, а дочитайте до конца — сейчас поймёте почему.

Для чего это сделано?

Я подозреваю, что такой подход был выбран из-за того, что xcache очень агрессивно кэширует байт-код php и после того как он был закэширован в памяти, оптимизатор попросту перестаёт проверять (или делает это крайне редко) был ли оригинальный скрипт изменён на диске. Это приводит к тому, что если работает xcache и вы отредактировали свой php файл, то изменения в работе скрипта вы увидите далеко не сразу, т. к. xcache попросту не подгрузит их из файла и не скомпилирует, а просто подставит данные из кеша. В режиме работы сервера (через fast-cgi) — такой ход оправдан, т. к. лишнее обращение к файловой системе на проверку изменений может, хоть и не сильно, но повлиять на производительность. Однако, кроме серверов, php скрипты могут быть запущены из консоли вручную или, к примеру, для отладки скрипта. В таком случае агрессивное кеширование играет очень плохую шутку с разработчиком — он вносит изменения, а результата изменений не видит — работает-то код из кэша. Я думаю именно поэтому и было сделано такое разделение в поведении оптимизатора, чтобы разработчки не рвали волосы на груди с криками «я изменил код, какого лешего он не работает!» при работе в php cli. Однако если вы уверены, что вам оптимизатор с хранилищем нужен в cli режиме — вы теперь знаете как его включать.

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

Happy coding! =)