Opcode/var кешер для PHP (мое сравнение)

Стал вопрос в выборе opcode/var кешера. Что от него нужно: собственноно кеширование opcode (понимается прекомпиленный и желательно оптимизированный byte код) в память, возможность кеширования в память переменных. Расмотрю то, что мне удалось найти и протестировать.

eAccelerator

http://eaccelerator.net/
По API больше понравился eAccelerator. API простое – только самое нужное, но есть и такие возможности, которых нет у других – функции блокировки ключа. Он также лучше и удобнее в настройках. Позволяет отдельно управлять хранением ключей, сессий и данных (скомпилированного кода и пользовательских данных). Методы хранения: только в разделяемой памяти, в памяти и на диске одновременно, в памяти с вытеснением на диск и только на диске. Легко и прозрачно можно отделить ключи каждого виртуального сервера в системе, чтобы не было лишних дырок в безопасности и пересечения ключей, установкой уникального значения параметра eaccelerator.name_space для каждого виртуального сервера. Против ожидания, что нагрузка на процессор и память возрастет, наблюдаю, наоборот, снижение за счет меньшей нагрузки на базу данных. При длительной эксплуатации загонял процесс в lock (обидно).

Плюсы:
По сторонним тестам самый шустрый (ИМХО – согласен);

Минусы:
На продакшн-сервере после n едниц времени работы загонял процесс в lock;

APC

http://www.php.net/apc
APC очень обилен в настройках. Настроек тоже много. API очень маленькое. Интересная функция – сохранение массива и восстановление его как набора констант. Редкая по нужности функция.

Плюсы:
Продвинутый, но не так как в XCache, admin интерфейс;
Входит в состав PECL;

Минусы:
Чуть медленнее XCache;
Он сакс;

XCache

http://xcache.lighttpd.net/

После eAccelrator и APC XCache ничем хорошим не удивил. Слабоватая документация по API, хотя для базовых функций даны примеры, и то хорошо. API простое. Из особенностей: возможность выполнять инкремент и декремент числового значения в кэше и функция проверки наличия ключа в кэше без пересылки самого значения. Настроек довольно мало. Удивило то, что кэширование по умолчанию разрешено, но размер используемой памяти и максимальные размеры пользовательских объектов равны нулю, что по документации означает «запрещено». Есть система чтобы обезопасить память, в которую он кеширует (Read-only protection).

Плюсы:
Поддержка наиболее свежих версий PHP;
Незначительное (около 3%) превосходство над APC;
Продвинутый admin интерфейс;
Есть интерфейс для работы в составе Zend_Framework;
Стабильность (если верить автору);

Минусы:
// пусто

Также, хочу вспомнить про ещё один кеширующий элемент, но он не кеширует opcode, но может кешировать все что вы пожелаете в памяти (переменные, страницы и прочее).

Memcache

http://www.php.net/memcache
Memcache минималистичен в настройках, так как настройки управления кэшированием находятся на стороне сервера memcached. API у него посложнее, чем у первых трех систем, и поддерживает работу в процедурном и ООП способах. Из особенностей: помимо функции установки значения по ключу есть возможность добавить ключ, только если его еще нет, и перезаписать, только если он уже есть. Может иметь несколько кэширующих серверов: как на том же хосте, так и на других. Как я понял, суть Memcache – в использовании ресурсов других хостов. По моему мнению, это несколько устарело: если ресурсов одного хоста не хватает, то лучше найти другой способ распределить нагрузку, чем коммуникация по TCP с кэширующими серверами на других хостах, что вносит существенную задержку.

Итог

Хочу заметить от себя, что самый шустрый оказался по моим тестам eAccelerator, но на рабочей системе он вганял процесы в lock. Поэтому пришлось его вырубить и заменить на XCache. XCache оказался чуть медленнее, но работает тоже хорошо, и пока стабильно на продакшан сервере. Memcache тоже отлично работает как кеширователь страниц и переменных (скорость работы его тоже очень велика, и не удивительно, ведь memcached – отдельный сервер). APC даже не испытывал, поскольку как и было указано сакс (если не прав – поправите меня).

ИМХО, в лидерах – eAccelerator и XCache (для кеширования opcode). APC работает в несколько раз медленнее, чем eAccelerator. А Memcache неплохо использовать для дополнительного кеширования.

Все. Удачи!

18. января 2009 by Alexey Vasiliev
Categories: memcache, PHP | Tags: , | 14 комментариев

Comments (14)

  1. а можно графики какие-нить?

  2. Все это замечательно, но из предложенных вариантов, только memcache допускает масштабирование. Поэтому, все остальное я бы рассматривал только с точки зрения opcode-кэшинга.

  3. 2Антон
    С такой точки зрения в основном я их и рассматривал (ведь это уменьшает нагрузку на высоконагруженый ресурс). А memcache я упомянул как как дополнение для кеширования (ведь его можно юзать в связкой с XCache, eAccelerator или APC)

  4. использую eAccelerator на порядка 40-ка серверах, нигде не загоняет процессы в lock.

  5. 2I
    Версия eAccelerator? А также сервера? У меня нагруженость – приблизительно 100 запросов в секунду, nginx 6.32, php5-cgi 5.2.4 (через fastcgi) и eAccelerator 0.9.5.3. Приблизительно через сутки некоторые php5-cgi процессы уходят в lock (когда онлайн растет). А у Вас как?

  6. А мы используем mod_php + eAccelerator и довольны по уши. Никаких lock’ов.

  7. 2 eAccelerator
    скиньте пожалуйста stack trace залоченного процесса, собранный в gdb (bt full)
    Барт достаточно адекватный перец, по багам общение достаточно продуктивно идёт.
    глядишь, исправление вашей проблемы через пару месяцев и в релиз какой войдёт.

  8. 2foxler
    Просто nginx для высоконагруженых систем более продуктивен (особенно для кластеров)
    2ihanick
    Сейчас уже не смогу это сделать, все-таки система production и экспериментировать на ней мне не дадут. Но вот готовиться на днях ещё сервер, воткну туда и посмотрю что будет.

  9. 2ihanick
    Хочу добавить, что такое происходит именно со скриптом, к которому ну ОЧЕНЬ много запросов в секунду (200-250 запросов в секунду). Кстати, XCache тоже (но реже) вганял в lock, пока не включил его систему Readonly Protection (http://xcache.lighttpd.net/wiki/ReadonlyProtection).

  10. как правило eaccelerator 0.9.5.3. php есть и 4-ой ветки и 5-ой (верси всегда последние в своей ветке). nginx 0.6.34, на некоторых серверах постарее, на некоторых отсутстует. apache тоже разный, как правило 1.3, на паре серверов 2.0, 2.2 на 10-ке серверов. как правило работает mod_php, но на некоторых mod_fcgid 2.2 (зачастую совместно с mod_php). На всех FreeBSD 6-7.
    у вас получается 250 млн. хостов в месяц? это много для одного сервера (только если вы не кучу статики раздоете), у нас на сервер приходится не больше 100 млн.

  11. 2I
    Я работаю с онлайн игрушкой, там чат, который и обновляется каждые 3 секунды для одного пользователя (плюс обновляется информация про пользователя, список пользователей, бои и дуэли в локации). Нагрузка приличная. И я долго искал проблему почему процесс уходил в lock (пересобирал ядра, ставил разный nginx, разный 5 PHP) пока не вырубил в один день eaccelerator. Так что есть, то и пишу (и эта проблема встречается не только у меня).

  12. а ос какая?