Среда, 16 Сентябрь. 2009
Добавил Балькин Руслан
Комментарии (21) Обратные ссылки (0) Тэги: accelerator, apc, blog, buddypress, eaccelerator, performance, php, wordpress mu, xcache, оптимизация, производительность
PHP-акселераторы при работе с WordPress MU и BuddyPress
Прочитав у 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. Related Links:Обратные ссылки
URI этой записи для создания обратных ссылок (trackback)
Нет обратных ссылок
Комментарии
Показывать комментарии
(Как список | Древовидной структурой)
Скорее всего кроме установки eA необходим тюнинг Apache, MySQL и PHP А какой именно тюнинг LAMP имеется в виду? В MySQL сделан стандартный для наших серверов тюнинг: уменьшен таймаут на дисконнект, уменьшено количество максимальных подключений, увеличен пул памяти InnoDB, включен query cache, увеличен размер кэша таблиц. В Apache сделано: MaxClients подобран таким образом, чтобы при этом значении подключений система не уходила в жесткий своппинг. PHP - собран с -O3 и правильным -march , сервер крутится на Gentoo. Ненужных экстеншенов нет. С -O3 синтетические тесты отрабатывали быстрее, чем с -O2 (хотя подозреваю, что проблема с eAccelerator может быть именно из-за компиляции PHP с флагом -O3). Конфигурация сервера да, слегка избыточная - но нужно, чтобы тот самый другой сайт работал всегда и работал хорошо. Другой сайт работает на ModX, все жизненно важные документы кэшируются, но основная причина достаточно мощного сервера - пара перенесенных небольших DDOS. Что-то Проблема только с самим WP MU - иногда в Визуальном редакторе не отображает панель инструментов, но думаю это все таки из-за глюков с правами на папки после обновления до 2.8.4a... + информ-сообщение что Feed для корня - пустой (хотя все ок) Потребление в админке (макс) - 21Mb, на лице (макс) 19Mb, общее потребление системы 300..400Mb, CPU не более 0.9 (я слаб в тонкостях Unix-овых показателей нагрузки на CPU) Кстати! Установка eA уменьшило потребление памяти на 30..70% (для разных блогов и страниц по разному), расход CPU вроде на одном уровне В визуальном редакторе да, тоже пропадала панель инструментов - у нас вроде бы дело было в 404 ошибках, можно в access.log / error.log найти. У нас например упорно искался русский язык для TinyMCE, отсутствовавший на сервере, и что-то еще. Больше как-то нету ничего, где производительность бы напрямую зависела от PHP. Всё равно чаще узким местом является база. Вероятнее всего, в CentOS в MySQL западло воткнуть патчи от Google, Percona и т.п. Я такой прожорливой системы как вордпресс, вообще в PHP-мире не видел. Все остальное работает примерно так: быстрая инициализация - медленные запросы в БД - быстрая обработка данных быстрый вывод на экран. А здесь же умудрились сделать медленными все 4 пункта. Впрочем, бывают и исключения конечно. У нас в основных проектах (Java и Grails) за счет использования персистентных кэшей, серверы баз данных практически простаивают. Один проект на CentOS - MySQL подкушивает проц и процессы, на FreeBSD - в конце топа сисид... везде php-fcgi - самое тормознутое в связке ;) Гоню кстати как троцкий про Яву. У нас в игре (клиентская, онлайн 200-500 человек) сервер обрабатывает где-то от 30 до 1000 запросов в секунду (самых разных, от "пинг" или "понг" до "сделай вот такой-то ход и расскажи мне, как изменилась ситуация" или же "а кто из игроков за последние 7 дней продавал карту такую-то"). Все данные из БД по вполне понятным причинам кэшируются в памяти. И тем не менее, потребление ресурсов MySQL'ом составляет до 50% от времени, затраченного виртуальной машиной Java. Это, правда, в основном торговля и статистика. Ровно из-за того, что данные регулярно изменяются (торговля, балансы игроков, рейтинги, уровни, статистика игровых достижений и т.п.). И это при том, что для сложных вопросов (типа "добавить всем 128 игрокам, участвующим в турнире, по 4 вскрытых ими бустера) - выполняются одномоментно хранимой процедурой. А вот с другим проектом из разработки всё веселее, там очень мало меняющихся данных и большая часть базы лежит в read-only кэше. Там накладные расходы от одной только инициализации фреймворка Grails больше, чем потребление процессора PostgreSQL'ом. // стресс-тест, 1000 активных яростно кликающих ботов. Кеш идет на всех уровнях (nginx, php, mysql) [--] Reads / Writes: 89% / 11% Ладно, бог с ним =) Проект интересный кстати. Я думал, beon всех уже окучил - ан нет Ж) |
Календарь
Быстрый поискКатегорииРекомендую сайтыПодпишись на RSSТэгиseo
s9y usability праздник grails отдых отпуск mysql samsung абхазия деньги озон windows berserk ноутбук gentoo я mac сервисы java игры хакинтош политика flash оптимизация groovy hackintosh mac os actionscript webmoney россия советы жизнь php asus программирование игра game eee linux flex LIFE online game саранск WWW блог онлайн игра blog берсерк СтатистикаОбновлен: 2012-01-26 09:05
321 постов
505 комментариев
0 посетителей онлайн
СчетчикиЭто тоже я |
|||||||||||||||||||||||||||||||||||||||||||||||||