Кэширование в Wordpress обзор плагинов

В этой статье приведем текст сравнения плагинов WP Super Cache vs HyperCache vs W3 Total Cache vs MaxSite Cache. Как видно из названий все плагины решают одну и ту же задачу, а именно пытаются посредством кэширования данных снизить нагрузку на сервер и повысить скорость отдачи страниц пользователям. Что ж посмотрим как это у них получается.


Для WordPress написано много кэширующих плагинов, предназначенных для увеличения скорости генерации и отдачи страниц, но какой же из плагинов выбрать?


Многие не без основательно не используют ни один из представленных плагинов, считая что страница всё-таки должна быть динамичной, мы в своей работе тоже придерживаемся данных правил, но если посещаемость вашего ресурса перешагнула тот порог когда нужно думать о производительности серверного оборудования, то возможно кэширование решит ваши проблемы еще на какое-то время. Но помните, прежде чем настраивать кэшинг загляните в статистику, её анализ порой дает поразительные результаты и выводы.


Далее идёт цитата умельца который собственно проводил тестирование:


Для теста была взята машина такое конфигурации: 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


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


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


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




В ходе тестирования выяснился абсолютный лидер — 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 делает то, что опытный системный администратор может настроить на уровне сервера.

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


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


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


Вот такие вот они мысли оптимизатора. Решайте сами иметь дело со всем перечисленным или же решать вопрос производительности другим путём.

Источник: http://blog.sjinks.pro/

на главную



Архив работы

agplr
2009-03-27 23:29:20
agplr.org.ua
Газпромпроект
2009-03-27 23:26:11
gpp.com.ua

agropartner
2009-03-27 23:23:00
/agropartner/
Британка немного о кошках
2009-02-26 22:55:47
britanka.com.ua
ФФЕА
2009-01-23 19:45:26
ffea.crimea.ua
ПППЛ
2008-12-22 00:43:02
pppl.org.ua
ООО АССА-В
2008-12-22 00:00:13
assa-v.com.ua