XCache — кэширование байткода

Как известно, 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.

#1

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

msfs11, 17.01.2012 - 10:04
#2

не, всё правильно.
для кэширования данных использую Memcache
для кэширования скриптов использую XCache

admin, 17.01.2012 - 10:18
#3

xcache.ttl = 0
xcache.gc_interval = 0
Почему оставили нулевыми?
Ведь если xcache.ttl выставить > 0 , то старые записи будут автоматически удаляться и не нужно будет удалять в ручную.
Ну а второй параметр - xcache.gc_interval, как я понял, удаляет мусор, то есть те записи, которые уже не потребуются. Так что тоже стоит установить в значение большее нуля.

koka, 26.04.2012 - 11:40
#4

а зачем? у меня почти ничего не меняется в плане файлов, т.е. они не устаревают. памяти хватает.

gc_interval>0 значит каждый раз xcache будет запускать дополнительный "процесс" на поиск устаревших файлов, примерно как в php происходит удаление просроченных сессий. такой процесс почти не нагружает сервер, но зачем он? упрощай всё как можно больше.

admin, 8.08.2014 - 18:10
Оставить комментарий