WP Super Cache vs HyperCache vs W3 Total Cache vs MaxSite Cache
Сравнение различных плагинов кэширования для WordPress
Для WordPress написано много кэширующих плагинов, предназначенных для борьбы со слабой производительностью сервера (либо кривыми руками администратора, который не в состоянии настроить PHP/MySQL). Простой пользователь зачастую задаётся вопросом: какой же из плагинов выбрать?
В данной статье я рассмотрю наиболее популярные плагины (WP Super Cache, Hyper Cache, W3 Total Cache и MaxSite Cache), а затем расскажу о результатах жестокого теста, которому я подверг все эти плагины.
Прежде, чем перейти к делу, отмечу, что я не фанат ни одного из плагинов и не использую их на своих сайтах, считая, что овчинка не стоит выделки: будущее за динамическими страницами 
Поехали.
- WP Super Cache написан Donncha O’Caoimh, одним из разработчиков WordPress. Про своё отношение к этому плагину я уже писал. Плагин разрабатывался как замена WP-Cache. Ключевой особенностью плагина является генерация статических HTML-страниц таким образом, что они будут отдаваться Web-сервером — минуя PHP.
- Hyper Cache. С ним я тоже сталкивался, и какое-то время плагин стоял у меня на сайте. Плагин написан гораздо проще, чем WP Super Cache и имеет более высокий рейтинг на wordpress.org.
- W3 Total Cache — новое слово в кэшировании. Поддерживает сжатие скриптов, CSS, кэш для базы данных, работу с CDN и многое другое.
- 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 потоков не тестировал.
| WordPress | WP Super Cache 0.9.7 | Hyper Cache 2.6.2 | MaxSite Cache Lite | W3 Total Cache 0.8 | ||||||
|---|---|---|---|---|---|---|---|---|---|---|
| Количество потоков | 100 | 100 | 500 | 100 | 250 | 100 | 500 | 130 | 100 | 130 |
| Время тестирования, с | 677.442 | 1.115 | 1.079 | 18.736 | 8.633 | 3.291 | 2.501 | 2.992 | 21.284 | 21.086 |
| Количество ошибок | 0 | 0 | 0 | 0 | 3663 | 0 | 2713 | 0 | 0 | 0 |
| Скорость, запрос/с | 14.76 | 8967.28 | 9268.36 | 544.20 | 1158.30 | 3038.98 | 3997.80 | 3341.72 | 469.84 | 474.25 |
| Среднее время обработки запроса, мс | 6774.423 | 11.152 | 53.947 | 183.757 | 215.833 | 32.906 | 125.069 | 38.902 | 212.838 | 274.116 |
| Среднее время обработки запроса по всем потокам, мс | 67.744 | 0.112 | 0.108 | 1.838 | 0.863 | 0.329 | 0.250 | 0.299 | 2.128 | 2.109 |
| Скорость передачи, Кбайт/с | 175.12 | 106154.90 | 109865.55 | 6393.68 | 8754.04 | 35537.15 | 34413.87 | 39075.95 | 4928.74 | 4974.58 |
| Порог завершения 95% запросов, мс | 9188 | 11 | 27 | 394 | 268 | 52 | 91 | 58 | 344 | 364 |
То, что не вошло в таблицу: средняя загрузка системы (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-запросов и знание принципов работы оптимизатора помогут переписать слабые запросы/добавить отсутствующие индексы в базу данных. Простор для действий довольно-таки большой. И динамика страниц остаётся
Связанные записи
Автор: Vladimir; опубликовано в: WordPress; метки: Hyper Cache, MaxSite Cache, W3 Total Cache, WordPress, WP Super Cache, нагрузка, производительностьНоя
2009
А я вот использую DB Cache Reloaded плагин. А почему Вы его не использовали в обзоре? Попутно наблюдение: я не знаю, может это Вами так задумано, но в файрфоксе 3,5, блоки “О себе”, “рубрики” и др. находятся внизу под записью, а выглядят так, как буд то должны быть справа.
Смотрите мой ответ на аналогичный вопрос.
Это временные технические нестыковки, я с шаблонами пока экспериментирую.
но всё же было бы интересно посмотреть его в сравнении. Просто на мой взгляд, он наиболее удобен в пользовании. Но реально, я даже не представляю насколько он полезен. А в целом, обзор интересный, спасибо за него.
спасибо за статью, очень полезно, давно ничего такого никто не делал. нашел через http://ocaoimh.ie/89495507/wp-super-cache-098/
у нас был блог с 800 000 monthly unique visitors, так wp super cache это единственный плагин кот. спасал от покупки дорогостоящих серверов. nginx использовать правда идея не приходила. теперь и он стоит =) получается nginx + wp super cache + eaccelerator + mysql query cache + wordpress code optimization. так и живем =) а да, еще статику на другой сервер вешаем. 3 Tb в месяц уходит ))
Если не секрет, какая у Вас конфигурация сервера?
владимир, у нас стоял Core2Quad Q9400, 8GB RAM, CentOS только для самого вордпресса + VPS гдето с 2gb Ram для статики где нужен был только большой траффик. в случае digg эффекта все равно главный сервер не всегда выдерживал, иногда падал. vps тоже часто зависал но так мы укладывались гдето в $250 в месяц что очень приемлимо было для нас учитывая что реклама окупала затраты. сейчас правда блог продан но от вордпресса мы не отошли и открыли хостинг провайдера недавно =) wooservers.com. будем опять раскручивать блог.
У нас Intel® Core™2 Quad CPU Q9550 @ 2.83GHz, 6144 KB L2 Cache, 8 GB RAM, Ubuntu
Server. В месяц пока уходит чуть больше 2 террабайт трафика. Правда, страничными кэшами вообще не пользуемся. Выглядит всё так: http://hvosting.sjinks.pro/munin/sjinks.pro/hvosting.sjinks.pro.html
На данный момент слабое место — это сеть: хостер ограничивает нас десятимегабитным каналом. Тоже склоняюсь к мысли взять VPS со стомегабитным каналом (только там 256 MB памяти и не более 10% потребление процессора). Пока не определился, как это всё дело синхронизировать.
да, с синхронизацией конечно проблема, зависит от контента. кто закачивает, кто использует. мы закачивали все сами поэтому просто сделали subdomain и повесили его на vps. или даже на несколько vps чтобы нагрузку раскинуть, как делают fishki.net например.
Could you run a benchmark comparison between WP Super Cache and Batcache? Wordpress.com uses Batcache to store pages in memory (RAM), much like W3 Total Cache does. I have tried all three and found that WP Super Cache performs the best under both Apache and Nginx.
I would like to see the benchmark test done on your server, so the test, and server configuration, will remain consistent as compared to the tests you have run with all the other caching plugins.
Thank you very much for all the good work you are doing here.
OK. Looks like BatCache requires MemCached.
Yes, mainly because the static files generated by the Super Cache are served by the web server and PHP does not have to be invoked. BatCache requires the PHP engine to load, parse several PHP files and execute BatCache’s code. These intermediary steps take some time. Because WP Super Cache does not require them, it works faster
Владимир, а поможет ли ваш или какой-то из опробованных вами плагинов в следующей ситуации?
У меня несколько сайтов WP 2.8.4-2.8.6 на shared-сервере. Сейчас стоят плагины WP Super Cache и WP-Optimize.
Но стоит начать в посещаемое дневное время редактировать статьи или одобрить пару комментов, как хостер отключает на 10 мин из-за перегрузки CPU.
А частенько и ночью в непосещаемое время вдруг видишь на графике CPU резкий всплеск сверх разрешенных 15% и отключение на 10 мин.
Плагины стоят только нужные.
MaxSite Cache поставил было в бесплатной версии, но он при некоторых шаблонах портит работу All-in-One SEO Pack и аналогичного Platinum SEO Pack.
Мешо, вопрос хороший.
Сайт какой — associatio.ru? Если да, то WP Super Cache там не работает (по крайней мере, в заголовках ответа это не видно). А еще nginx неправильно настроен — он вообще не выдаёт ошибку 404.
Хостер не говорит, какой именно скрипт вызывает перегрузку?
Обычно такие проблемы лечатся настройкой сервера, но в случае shared-хостинга это невозможно. Для того, чтобы WP Super Cache нормально работал в Full On mode, нужно править конфиги nginx, вряд ли хостер на это пойдёт, так что WP Super Cache отпадает.
Если Вас устраивает MaxSite Cache, и у Вас есть навыки отладки PHP-скриптов, возможно, будет проще допилить MaxSite Cache/All in One SEO Pack.
Владимир, хостер отправляет логи смотреть. Что я и делаю периодически, когда уж слишком сильно зашкаливает. Забанил пока несколько подозрительных роботов, а виновный скрипт так пока и не выявил. У другого человека тоже возникла похожая проблема (ночью вдруг появляется сильная кратковременная нагрузка). И мы безрезультатно обсуждали это на http://mywordpress.ru/support/viewtopic.php?pid=55273#p55273
Аксакалы форума почему-то промолчали.
А у меня подобные всплески нагрузки бывают не только ночью, но и во время большой посещаемости. А уж комменты днем одобрять и вовсе перестал.
Тогда я отключил WP Super Cache и поставил MaxSite Cache на семи блогах с 5-ю разными темами WP.
На двух темах он работает нормально. На трех других при включенном кэшировании тайтл, созданный All-in-one или Platinum Seo Pack, преобразуется в неоптимизированный исходный тайтл WP. Вывод: на 3-х из 5-ти вполне нормальных тем тайтлы сбиваются из-за MaxSite Cache – большой процент, и у других людей – тоже. А что может быть не так в шаблонах, в какую сторону “копать”?
Мишо, не могли бы Вы мне кинуть на email темы (vladimir мяу sjinks точка org точка ua)? Хочу попробовать. У меня есть серьёзное подозрение, что проблема связана с буферизацией вывода. Попробую посмотреть, что можно сделать.
Владимир, отправил вам на почту.
WordPress 2.8.6, последний All in One SEO Pack, MaxSite Cache Lite — всё работает. Вероятно, конфликт с каким-то другим плагином.
Спасибо, что подсказали! Попробовал сейчас – тоже работает!
То ли Макс что-то починил, а может, сыграло роль обновление All in One SEO Pack… Буду пробовать дальше.
Владимир, а что вы думаете по поводу скрипта кэширования, предложенного в сообщении #6 темы http://mywordpress.ru/support/viewtopic.php?pid=59879#p59879
Это еще более облегчённая версия MaxSite Cache Lite
Принцип работы один и тот же. Основное отличие — в этом варианте кэш при необходимости придётся удалять вручную (у Макса же используется специальный URL).
[...] [...]
[...] лишает ряда возможностей. О многих аспектах кеширования Вордпресс очень хорошо, вкусно и подробно написано у Владимира [...]
Предлагаю включить в тестирование
http://centavrus-opti.ru/skript-keshirovaniya-dlya-wordpress.html
в ответ поставлю ссылку со своего блога на этот или как-нибудь еще думаю договоримся