PHP-акселераторы при работе с WordPress MU и BuddyPress

· На чтение уйдёт 3 минуты · (557 слов)

Прочитав у slaFFikстатью про потребление памяти WordPress MU 2.8.2 и BuddyPress, заинтересовался, насколько эффективно у нас на Берсерках.Ру экономит расход памяти акселератор. В то время использовался eAccelerator, кэш опкода составлял 64 Мб. После экспериментов выяснилось, что увеличение кэша опкодов до 128 Мбайт действительно привело к радикальному снижению расходования памяти, с 35-36 Мбайт до 18 на процесс. Поскольку количество одновременных доступов к сервису может превышать 4, - мы решили увеличить кэш опкода, чем вызвали существенное снижение потребления памяти. Однако, не прошло и суток, как стала наблюдаться крайне неприятная ситуация - при простых операциях с сервером, иногда результатом действия была белая страница, а в логе ошибок сервера появлялось сообщение о том, что процесс apache был убит в результате ошибки. Было принято решение сменить акселератор - я попробовал xcache и APC (из PECL). И вот что получилось: Наиболее эффективным среди троицы eAccelerator, xCache и APC оказался изначально стоящий у нас на сервере eAccelerator. Благодаря его 128 Мбайтном кэшу опкода, наблюдалась стабильно быстрая загрузка страниц, хоть свежих, хоть "залежавшихся". Потребление памяти было 16 Мб при неоптимизированном коде. К сожалению, при включенном кэше опкода (причем именно когда кэшировался код WordPress MU - при 64 Мбайт кэша и стандартном 36-меговом потреблении памяти апач сам по себе не падал) наблюдались проблемы со стабильностью Apache. Вместе с тем, на других CMS - в частности, на ModX и MediaWiki, eAccelerator у нас работал без проблем. Настал черед попробовать APC, которому я доверял из-за того, что он включен в PECL. Реальность меня повергла в ужас, апач начал падать с завидной регулярностью, потребление памяти же было около 18 Мбайт. Затем кэш опкода, видимо, переполнился и сервер начал тормозить настолько сильно, что я с трудом смог остановить Apache и попробовать XCache. К слову, в кратковременный период, когда сервер был запущен совсем без акселератора, - ничего не тормозило. Последним кандидатом был XCache. Результаты его работы были довольно-таки средними. По всем показателям он уступал eAccelerator'у, но уступал лишь незначительно. Кстати - сервер двухядерный, использовалось три кэша (как и советовали разработчики XCache). На следующий день произошло переполнение кэша, однако сервер функционировал нормально. Память в последующие дни увеличивалась, до тех пор, пока мы не дошли до 224 Мбайт. Кэш переменных отключен. Apache стал работать стабильно, однако "холодный старт" скриптов был по-прежнему медленным. Иногда на загрузку заглавной страницы уходило до 3х секунд, при этом WP Tuner писал, что около 2х секунд было потрачено на загрузку PHP файлов. Итого, резюмирую собственный опыт работы с eAccelerator, xCache и APC. eAccelerator оказался самым производительным, но при работе с WordPress MU наблюдались проблемы (в частности, с RSS плагинами - на тех блогах, где импортировались RSS фиды - были пустые места) с падением apache. Объем памяти, необходимый для кэша, был минимальным среди указанных акселераторов. В случае переполнения кэша проблем с производительностью не было. APC - самый ужасный среди протестированных акселераторов. Проблемы с падающим Apache, быстро закончившийся кэш опкода, ужасные проблемы с производительностью при переполнении кэша опкода. Этот акселератор меня не успел порадовать абсолютно ничем, был отправлен "в топку" очень быстро, примерно в течение часа. xCache - крепкий середнячок. Прирост производительности и улучшение потребления памяти - на уровне eAccelerator, вместе с тем - проблемы с производительностью при "холодном старте". Нужно в два раза больше памяти под кэш опкода, чем eAccelerator'у. Использовалась такая платформа: сервер на однопроцессорном Intel Core 2 Duo, архитектура x86_64. PHP и расширения собраны с оптимизацией -O3. PHP 5.2.10. Apache 2. Из других важных PHP-расширений - Suhosin.
Полезное