Вторая часть статьи WP Super Cache vs MaxSite Cache.

В предыдущей части я сравнивал поведение MaxSite Cache и WP Super Cache на тестовом VDS (512 MiB RAM, 10 GB HD, Intel Xeon X3320 (1 ядро), 2.5 GHz), на котором ни операционная система, ни программное обеспечение не были специально настроены — бралась конфигурация «из коробки» и тестировалась. Одним словом, «VDS абсолютного чайника».

В этой части изменилась только конфигурация программного обеспечения: сервер настраивался на максимальную производительность.

В частности:

• отказ от Apache в пользу nginx и от mod_php5 в пользу php-fcgi (количество FastCGI-процессов выбиралось таким образом, чтобы избежать использования файла подкачки);
• смена ядра с linux-image-server на linux-image-virtual;
• настройка MySQL: отказ от InnoDB (экономит примерно 100 МБ памяти), увеличение буфера ключей и т.п.;
• установка и настройка xCache (я исходил из того, что далеко не все чувствуют себя комфортно при сборке программ из исходников, поэтому брал только готовое ПО);
• настройка iptables для фильтрации пакетов.

Методика тестирования осталась прежней: карта сайта преобразовывалась в список адресов, на этот список натравливался siege, а я присматривал за сервером и вносил коррективы в конфигурацию ПО (да, с первого раза трудно всё настроить идеально).

Чтобы убедиться, что новая конфигурация не хуже старой, я полностью отключил кэширование и имитировал 50 одновременных посетителей в течение 15 минут. На момент выполнения теста у сервера было свободно 348.5 МиБ памяти.

Данные загрузки/потребления памяти очень приблизительны. Хотя вряд ли пользователи станут ждать по 9 секунд загрузку страницы, радует, что сервер не ответил только на один запрос и не ушел в нокдаун. Простая экстраполяция показывает, что сервер выдержит примерно 463,000 обращения к PHP-страницам в сутки.

Мы убедились, что новая конфигурация вполне жизнеспособна (старой до неё, как до Китая в неудобной позе), переходим к тестированию плагинов.
Тестирование проходило в 30 и 75 потоков. Я не разделял фазы построения и использования кэша.

Краткие выводы: на грамотно настроенном сервере лидирует WP Super Cache — и по скорости, и по создаваемой нагрузке. Это связано с тем, что задача по отдаче закэшированного контента переложена на web-сервер. Так как web-сервер справляется со статикой быстрее, чем с динамикой, в результате получаем рост производительности и снижение нагрузки.

Если по той или иной причине WP Super Cache не может работать в режиме Full On, то MaxSite Cache будет всё же предпочтительнее — ввиду своей простоты он обладает исключительным быстродействием.

© 2012 Ars Longa, Vita Brevis. Все права защищены. Перепубликация материалов без разрешения автора запрещена.

При использовании материалов блога наличие активной не закрытой от индексирования ссылки на источник обязательно.

После того, как MAX’у не понравился тест с участием MaxSite Cache, я решил несколько видоизменить методику тестирования.

На этот раз я тестировал только два кэша: WP Super Cache и MaxSite Cache Lite.

Так как по словам MAX’а в реальности все ставится «из коробки», я взял виртуальный сервер (512 MiB RAM, 10 GB HD, Intel Xeon X3320 (1 ядро), 2.5 GHz), на который поставил Ubuntu 8.04 LTS Server Edition. Затем поставил Apache (2.2.8-1ubuntu0), PHP (5.2.4-2ubuntu5.6) и MySQL (5.0.51a-3ubuntu5.4). Конфигурационные файлы брались «из коробки» (только для Apache пришлось включить mod_rewrite), в системной конфигурации абсолютно ничего не менялось. VDS абсолютного «чайника». Для мониторинга ресурсов системы установил munin (он рисует такие красивые графики).

Кому интересно, VDS конфигурировался так:

Затем я поставил WordPress 2.8.5 с официального сайта, импортировал в блог порядка 800 статей среднего размера (авторство статей не моё, так что выложить не могу).

Вместо Apache Bench я использовал Siege, обращение производилось ко всем страницам сайта в случайном порядке (вероятность обращения к заданной странице задавалась количеством её повторений в файле с адресами). Тестирование каждого варианта (WP Super Cache и MaxSite Cache) проводилось по 45 минут — 30 минут при низкой нагрузке и 15 минут при высокой (увы, трафик не безлимитный, и раскидываться гигабайтами трафика для теста возможности пока нет). Это имитировало постепенный наплыв пользователей на сайт. Специфика теста такова, что новый запрос не выполнялся до тех пор, пока не завершался предыдущий.

Одновременно к страницам обращалось 30 пользователей (Apache просто больше не выдерживает). Между тестами системе перезагружалась (на всякий случай). Виртуальный сервер и сервер, с которого осуществлялось тестирование, были, естественно, разными; соединены гигабитным каналом.

Результаты получились очень интересными: MaxSite Cache Lite строит кэш несколько быстрее, чем WP Super Cache (у MaxSite Cache более простая логика работы). WP Super Cache создаёт более сильную нагрузку на диск (так как файлы разбрасываются по множеству каталогов, а не кидаются в один) и, за счёт этого, чуть большую нагрузку на процессор (если сравнивать по значению idle time). Но при этом у WP Super Cache больший коэффициент параллельности (обслуживает большее число запросов одновременно).

Но при отдаче кэша и с повышением нагрузки результат меняется: WP Super Cache отдаёт данные быстрее и, как результат, обслуживает большее количество клиентов. Потребление памяти при этом чуть меньше, но загрузка процессора чуть больше. Вообще картину очень сильно портил munin — нагрузка, им создаваемая, вносила существенные погрешности в измерения (было видно в top).

Краткие выводы: в плане построения кэша производительность у MaxSite Cache Lite выше, что объясняется простотой его логики. Но при нагрузке и построенном кэше WP Super Cache обладает более высокой производительностью, так как web-сервер способен отдавать закэшированные данные без привлечения PHP. При одинаковом количестве запросов в секунду под нагрузкой WP Super Cache демонстрирует меньшее потребление памяти и нагрузку на процессор. При средней нагрузке на систему оба кэша ведут себя примерно одинаково — разница в потреблении памяти и нагрузке незаметна.

В следующей части: тест WP Super Cache и MaxSite Cache на грамотно настроенном сервере.

© 2012 Ars Longa, Vita Brevis. Все права защищены. Перепубликация материалов без разрешения автора запрещена.

При использовании материалов блога наличие активной не закрытой от индексирования ссылки на источник обязательно.

Для WordPress написано много кэширующих плагинов, предназначенных для борьбы со слабой производительностью сервера (либо кривыми руками администратора, который не в состоянии настроить PHP/MySQL). Простой пользователь зачастую задаётся вопросом: какой же из плагинов выбрать?

В данной статье я рассмотрю наиболее популярные плагины (WP Super Cache, Hyper Cache, W3 Total Cache и MaxSite Cache), а затем расскажу о результатах жестокого теста, которому я подверг все эти плагины.

Прежде, чем перейти к делу, отмечу, что я не фанат ни одного из плагинов и не использую их на своих сайтах, считая, что овчинка не стоит выделки: будущее за динамическими страницами

Поехали.

1. WP Super Cache написан Donncha O’Caoimh, одним из разработчиков WordPress. Про своё отношение к этому плагину я уже писал. Плагин разрабатывался как замена WP-Cache. Ключевой особенностью плагина является генерация статических HTML-страниц таким образом, что они будут отдаваться Web-сервером — минуя PHP.
2. Hyper Cache. С ним я тоже сталкивался, и какое-то время плагин стоял у меня на сайте. Плагин написан гораздо проще, чем WP Super Cache и имеет более высокий рейтинг на wordpress.org.
3. W3 Total Cache — новое слово в кэшировании. Поддерживает сжатие скриптов, CSS, кэш для базы данных, работу с CDN и многое другое.
4. MaxSite Cache — отечественная разработка, при этом платная. Я тестировал Lite-версию, так как покупать полную версию чисто для тестирования желания нет. По словам автора, выйдет абсолютным победителем при сравнении с WP Super Cache и компанией.

Для теста была взята машина такое конфигурации: Intel(R) Xeon(R) CPU X3320 @ 2.50GHz, 4 ядра, 3 MiB кэш, 8 GiB DDR-2 RAM, 2×500 GB SATA, RAID1 (ARC-1210 4-Port PCI-Express to SATA RAID Controller), 82572EI Gigabit Ethernet Controller.
Операционная система: Ubuntu 9.10 64-bit Server Edition
Веб-сервер: nginx 0.8.19
PHP: 5.2.10.dfsg.1-2ubuntu6.1 (FastCGI) + xCache 1.2.2-5, 75 процессов.

На тестируемой странице 25 несложных запросов, время их выполнения — 0.00993 сек.

На сайт натравливался ApacheBench — 10,000 запросов в 100…500 потоков. Это создаёт весьма приличную нагрузку, так как запросы идут один за другим.

Базовая нагрузка — 100 параллельных потоков. Я увеличивал количество потоков до тех пор, пока web-сервер не стал отдавать ответ, отличный от 200. Более 500 потоков не тестировал.

То, что не вошло в таблицу: средняя загрузка системы (load average) при тесте голого WordPress зашкаливала за 60. При тесте WP Super Cache и MaxSite Cache я не успевал ее измерить (была ничтожной). С Hyper Cache и W3 Total Cache загрузка доходила до где-то 10. Так что кэширование работает и выполняет свою работу — снижает нагрузку на сервер.

«Голый» WordPress тестировать более, чем со 100 потоками смысла нет

В ходе тестирования выяснился абсолютный лидер — WP Super Cache. Скорость отдачи кэшированных страниц поистине фантастическая — почти 800 мегабит/сек. Хотя такая скорость — это больше заслуга nginx.

MaxSite Cache Lite на 100 параллельных потоках проиграл WP Super Cache практически в пять раз! Причина понятна: WP Super Cache создает статические файлы так, что web-сервер их может отдавать клиенту без привлечения PHP-интерпретатора. А статические запросы при прочих равных всегда быстрее динамических. Так что платить 30 WMZ за полную версию MaxSite Cache я пока не готов

Среди остальных плагинов MaxSite Cache выигрывает благодаря свой простоте: минимум проверок, никаких регулярных выражений и лишних подключаемых файлов. Но даже такой подход не спасёт от хорошего SlashDot-эффекта: какой-то процент пользователей будет видеть ошибку сервера, для других возрастёт время генерации страницы. Это касается и остальных плагинов. Мораль: подключение PHP-интерпретатора — дорогое удовольствие.

По поводу масштабируемости: более 130 потоков не пережил ни один кэш (кроме WP Super Cache).

Аутсайдером, на мой взгляд, оказался W3 Total Cache — при почти одинаковой с Hyper Cache нагрузкой на сервер, время отдачи страниц было значительно выше. Хотя если бы тест был не таким искусственным, то производительность W3 Total Cache могла быть и более высокой. Хотя во многом W3 Total Cache делает то, что опытный системный администратор может настроить на уровне сервера.

Вообще плагины кэширования обладают очень интересной особенностью: они переносят нагрузку с одной подсистемы (процессор) на другую (диск). Так что на десктопном железе, слабых дисках или виртуальных серверах кэш может ухудшить ситуацию: процессор будет тратить время не на выполнение кода, а на ожидание завершения ввода/вывода (iowait). Так что при большом количестве оперативной памяти имеет смысл создавать RAM-диск и помещать кэш на него.

Кстати, даже при хорошей дисковой подсистеме, но при малом объеме оперативной памяти при большом объеме кэша могут возникать проблемы: например, если дисковый кэш у операционной системы мал, то при интенсивном равномерном обращении к разным страницам может возникнуть большая дисковая активность.

Вообще, как показывает мой опыт, прежде чем использовать плагин кэширования страниц, имеет смысл все же грамотно настроить сервер (обращайтесь). Например, если вместо Apache поставить nginx, можно освободить довольно много драгоценной памяти (prefork у Apache — это весьма сильный убийца производительности); если увеличить размер буфера ключей MySQL, можно добиться уменьшения дисковой активности. Если поставить opcode cacher (APC, xCache, eAccelerator), то можно значительно снизить затраты на перекомпиляцию PHP-кода и уменьшить время отклика системы. Если использовать оптимизатор, встроенный в eAccelerator, то можно повысить производительность PHP-кода. Анализ производительности MySQL-запросов и знание принципов работы оптимизатора помогут переписать слабые запросы/добавить отсутствующие индексы в базу данных. Простор для действий довольно-таки большой. И динамика страниц остаётся

© 2012 Ars Longa, Vita Brevis. Все права защищены. Перепубликация материалов без разрешения автора запрещена.

При использовании материалов блога наличие активной не закрытой от индексирования ссылки на источник обязательно.