WP Super Cache и высокая нагрузка: часть 2
Стоит ли овчинка выделки?
Вчера я наконец-то поднял 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 и т.п.) со включенным и выключенным кэшем. Возможно, что результат очень сильно удивит
Связанные записи
Автор: Vladimir; опубликовано в: WordPress; метки: munin, WordPress, WP Super Cache, кэш, нагрузка, плагин, производительностьИюль
2009




Меня зовут Владимир, я программист-фрилансер, специализирующийся на Web-программировании и програмировании под Linux.
По совместительству занимаюсь администрированием LAMP/LNMP-серверов и техническим переводом.






А чего свой WP File Cache не ставите на эти сайты? Интересно было бы посмотреть результаты.
Если бы это были мои сайты, я бы попробовал. Но, скажем так, я просто предоставляю хостинг. У FileCache будет та же болезнь, но в меньшей степени (хотя все зависит от установленных плагинов).
Sasha, мой SJ Object Cache на сайтах уже стоит.
Если интересно, вот графики munin. В будние дни на сервере порядка 40,000 посетителей, в выходные и того больше.
С удовольствием читаю вас,интересно и познавательно
А не подскажете, существуеи ли такой плагин, который позволял бы производить полное кэширование всего сайта на вордпресс, допустим, раз в сутки? То есть, проходил бы по сайтмэпу, генерировал бы статику, и отдавал бы её всем весь день, и ничего больше не делал бы. Такое бывает?
Спасибо за ответ заранее
Без понятия.
wget по крону — первое, что приходит на ум.
сорри за офф-топ, но
запустите китайского поискового бота… ну и доступ ему давайте ночью
пс.ы: wget – тяжело…
Ну можно Siege
Сайтмап можно легко преобразовать в список URL, который потом скормить siege.
А вообще мне подсказали плагин Really Static. Но я его не ставил.
[...] данного плагина, читайте в следующей статье – WP Super Cache и высокая нагрузка, часть 2, Стоит ли овчинка [...]
для wUUb
такое можно сделать и без плагинов
кешируем вордпресс без плагинов
И вся админка тоже будет кэшироваться?
да вроде не должно, мы же меняем index не для /wp-admin
Я выразился неправильно. Если зайти на сайт под админом, то простому пользователю будут отданы страницы из кэша админа. То есть у него будет возможность просмотра черновиков и личных постов. Ну и если тема отображает для администратора какие-то дополнительные данные, то и их тоже
Можно включить кеширование на стороне Nginx, Apache… как показала практика – в итоге резко снижается среднесуточная нагрузка на сервер…
Кстати, нужно на сервере протюнить ядрышко… под конкретные нагрузки…
Достаточно просто выбрать правильное ядро