Кэширование позволяет снизить нагрузку на сервер и ускорить загрузку страниц у пользователей. У WordPress есть много плагинов для кэширования сайтов. Но я хочу уделить внимание четырем, самым известным — WP Super Cache, Hyper Cache, W3 Total Cache и MaxSite Cache. Про первый я уже писал. В интернете наткнулся на интересную статью с их сравнением.
Вначале вкратце о них:
- WP Super Cache создан Donncha O’Caoimh, одним из разработчиков WordPress. Про него я уже писал отдельно. Плагин создан для замены WP-Cache. Основная особенность — создание HTML страничек, которые будут грузится вместо статичных PHP.
- Hyper Cache у меня стоит на одном из сайтов. У плагина рейтинг выше, чем у предыдущего.
- W3 Total Cache — плагин который позволяет кэшировать все, в прямом смысле, ведь он кеширует даже запросы к базе.
- MaxSite Cache платный плагин, которые создали российские разработчики.
Автор, Владимир, проводил тестирование на компьютере:: Intel(R) Xeon(R) CPU X3320 @ 2.50GHz, 4 ядра, 3 MiB cache, 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 параллельных потоков.
| 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. Так что кэширование работает и выполняет свою работу — снижает нагрузку на сервер.
Итоги:
Абсолютный лидер — WP Super Cache. Скорость отдачи кэшированных страниц поистине фантастическая — почти 800 мегабит/сек. Хотя такая скорость — это больше заслуга nginx.
MaxSite Cache Lite на 100 параллельных потоках проиграл WP Super Cache практически в пять раз! Причина понятна: WP Super Cache создает статические файлы так, что web-сервер их может отдавать клиенту без привлечения PHP-интерпретатора. А статические запросы при прочих равных всегда быстрее динамических.
Среди остальных плагинов MaxSite Cache выигрывает благодаря свой простоте: минимум проверок, никаких регулярных выражений и лишних подключаемых файлов. Но даже такой подход не спасёт от хорошего SlashDot-эффекта: какой-то процент пользователей будет видеть ошибку сервера, для других возрастёт время генерации страницы. Это касается и остальных плагинов. Мораль: подключение PHP-интерпретатора — дорогое удовольствие.
По поводу масштабируемости: более 130 потоков не пережил ни один кэш (кроме WP Super Cache).
Аутсайдером, на взгляд Владимира, оказался W3 Total Cache — при почти одинаковой с Hyper Cache нагрузкой на сервер, время отдачи страниц было значительно выше. Хотя если бы тест был не таким искусственным, то производительность W3 Total Cache могла быть и более высокой. Хотя во многом W3 Total Cache делает то, что опытный системный администратор может настроить на уровне сервера.
Вообще плагины кэширования обладают очень интересной особенностью: они переносят нагрузку с одной подсистемы (процессор) на другую (диск). Так что на десктопном железе, слабых дисках или виртуальных серверах кэш может ухудшить ситуацию: процессор будет тратить время не на выполнение кода, а на ожидание завершения ввода/вывода (iowait). Так что при большом количестве оперативной памяти имеет смысл создавать RAM-диск и помещать кэш на него.
Кстати, даже при хорошей дисковой подсистеме, но при малом объеме оперативной памяти при большом объеме кэша могут возникать проблемы: например, если дисковый кэш у операционной системы мал, то при интенсивном равномерном обращении к разным страницам может возникнуть большая дисковая активность.
Вообще, как показывает опыт, прежде чем использовать плагин кэширования страниц, имеет смысл все же грамотно настроить сервер. Например, если вместо Apache поставить nginx, можно освободить довольно много драгоценной памяти; если увеличить размер буфера ключей MySQL, можно добиться уменьшения дисковой активности. Если поставить opcode cacher (APC, xCache, eAccelerator), то можно значительно снизить затраты на перекомпиляцию PHP-кода и уменьшить время отклика системы. Если использовать оптимизатор, встроенный в eAccelerator, то можно повысить производительность PHP-кода. Анализ производительности MySQL-запросов и знание принципов работы оптимизатора помогут переписать слабые запросы/добавить отсутствующие индексы в базу данных. Простор для действий довольно-таки большой. И динамика страниц остаётся.
Полная версия статьи тут
Хм… Как раз на эту тему думал, а тут такой пост шикарный, спасибо!
На страничке про WP Super Cache внизу есть картинка, как у меня на сервере уменьшилось потребление памяти.