Вторая часть статьи 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. Все права защищены. Перепубликация материалов без разрешения автора запрещена.

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

Вчера я наконец-то поднял munin и новый monit на сервере, а сегодня посмотрел на результаты мониторинга. Самое первое, что бросилось в глаза: iostat показывает очень большое количество записей (превышавшее количество чтений почти в тысячу раз).

На сервере живут четыре сайта на WordPress, два из которых (littlefox.ru и cat-tv.ru) находятся в Alexa Top 100,000 (они создают основную нагрузку на сервер).

Особенность обоих сайтов — они используют небезызвестный плагин WP Super Cache. Мне с этим плагином приходилось неоднократно сталкиваться, и не всегда с хорошей стороны (так получилось), так что я имею представление о том, как он работает.

С целью поэкспериментировать мы отключили WP Super Cache. В результате получилась такая картина.

Так сложилось, что WP Super Cache мы отключили практически при пиковой посещаемости (хорошо видно на графике «eth0 traffic»), и тем интереснее смотрятся результаты. Практически сразу упало количество записей на диск (дисковая подсистема вздохнула с облегчением): при количестве записей, тысячекратно превышающих количество чтений, эффективность дискового кэша, очевидно, падает. В случае с виртуальным сервером такая нагрузка могла бы его положить: дело в том, что виртуализаторы не очень хорошо справляются с операциями ввода/вывода (это их слабое место); как результат, от этого начинает увеличиваться нагрузка на процессор (все больше времени проводится в iowait).

Также, как это ни странно, упала нагрузка на процессор! Причём заметнее всего это отразилось на user time (а не на system, как можно было бы ожидать) — если внимательно посмотреть на графики «CPU Usage» и «Load Average», то можно заметить, что при примерно одинаковом количестве посетителей (я сужу по объемам отдаваемого трафика) нагрузка при отключенном WP Super Cache оказывается меньшей (причем это заметно даже при низкой нагрузке — впрочем, при низкой нагрузке, наверное, любой кэш не особо эффективен из-за затрат на реализацию кэширования)! Так же уменьшилось количество переключений контекста (что, видимо, и объясняет уменьшение system time) и уменьшилось количество прерываний от контроллера жесткого диска.

А вот статистика MySQL далеко не однозначна:

С одной стороны, вроде бы и среднее количество запросов в секунду резко упало, но с другой стороны, это произошло до отключения WP Super Cache. Также заметно, что при выключенном WP Super Cache кэш запросов стал медленно таять (хотя это можно объяснить падением нагрузки и чисткой кэша). Хотя процентное отношение количества запросов, результат для которых был взят из кэша, весьма впечатляет. Что значит грамотная настройка MySQL. Тем не менее, данных для однозначных выводов недостаточно.

Перейдём к ответу на вопрос, стоит ли овчинка выделки. Как обычно, однозначного ответа нет. Нужно смотреть в каждом конкретном случае. Тем не менее, если сайт стоит на виртуальном сервере, то высокая нагрузка при включенном WP Super Cache может его убить. Если есть достаточно памяти (что на виртуалках большая редкость), то имеет смысл помещать каталоги с кэшем на RAM-диск и разгрузить дисковую подсистему. При высокой нагрузке на выделенном сервере нужно очень внимательно смотреть на конфигурацию MySQL, а также типы запросов. Если же сайт стоит на shared-сервере, то выбор здесь небольшой: либо отказаться от плагинов, которые грузят MySQL, либо сменить WordPress на что-то более легкое. Кэширование на shared-сервере, как правило, не оправдывает себя (во многом зависит от жадности хостеров, которые на одном сервере стремятся разместить как можно большее количество сайтов). Тем же, кто имеет административный доступ на сервер, я бы очень рекомендовал мониторинг сервера (munin, nagios/nagvis и т.п.) со включенным и выключенным кэшем. Возможно, что результат очень сильно удивит

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

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

Проблема: PHP случайным образом перестаёт реагировать на внешние запросы.

Сайт работает на WordPress (с WP Super Cache), web-сервером стоит nginx, php-fpm с 40 дочерними процессами висит в режиме FastCGI. Довольно-таки стандартная конфигурация.

Иногда (периодичность не ясна) сайт падает. В том плане, что nginx выдаёт ошибку 502 Bad Gateway. При этом в логах отображается примерно такое:

Лечится только перезапуском php-fpm.

Ошибка очень интересная и нестандартная: один и тот же PHP обслуживает двух разных пользователей, соответственно, имеется два пула дочерних процессов. При этом висит только один пул. Следовательно, это не должна быть ошибка в FPM, иначе бы висело всё.

К счастью, php-fpm имеет один замечательный инструмент отладки: лог запросов к скриптам, выполняющихся дольше определённого времени с backtrace вызовов функций (нечто типа debug_backtrace() в PHP).

Оставил всё это дело на ночь, а наутро в логах получилась примерно такая картина (я оставил только уникальные backtrace):

Запросов первого типа было очень много, и они заняли все процессы, стрелки указывают на WP Super Cache. То, что проблема именно с семафором, подтверждает вывод ps -C php-cgi -opid,state,wchan:25,args:

S означает «сон, который можно прервать» (ожидание свершения события), а semtimedop — функция, в которой процесс уснул.

Так как в пуле 40 процессов, и все 40 процессов спят, имеем проблему с синхронизацией. Особенно смущает засыпание в flock_lock_file_wait — по идее, WP Super Cache использует либо семафоры, либо файловую блокировку, но вероятно, я что-то не учитываю (ибо не kernel developer).

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

В общем, буду копать код WP Super Cache и искать баги.

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

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

Сборная солянка с нескольких форумов (ссылок, к сожалению, не дам, но Google может помочь); данная конфигурация является рабочей.

Этот блок нужно вставлять до основных правил переписывания адресов (в идеале сразу после root).

Детали конфигурирования nginx для WordPress описаны в статье «Конфигурация nginx для WordPress: критический взгляд со стороны».

Можно сделать проще: поместить правила для WP SuperCache в /etc/nginx/includes/wpsupercache.conf, а из конфигурации виртуального хоста делать include /etc/nginx/includes/wpsupercache.conf; — работать будет, так как конфигурация WP Super Cache не зависит от внешних параметров.

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

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