Кэширование: Разгоняем Wordpress, тест плагинов кэширования.
Краткое введение в кэширование.
Кэширование – сохранение промежуточных (однотипных вычислений) или окончательных (данных) результатов работы скрипта (программы, движка сайта, CMS) во временном хранилище (кэширование возможно производить в файловую систему – дисковый кэш, в оперативную память или в базу данных), с целью дальнейшего замены или уменьшения работы скрипта, то есть, по мере надобности, данные или результаты работы скрипта извлекаются из хранилища (кэша), не тратя время на процесс обработки информации (работу скрипта), вследствие чего, кэширование позволяет ускорить процесс вывода информации пользователю.
Существует много вариантов кэширования, которые отличаются как по способу кэширования, так и по типу кэша, Ниже представлен список основных направлений в области веб-кэширования:
-
Кэш запросов (СУБД);
-
Файловый кэш, кэширование в файлах;
-
Кэширование методом дерева (дерево кэша);
-
Кэширование веб, HTTP;
-
Ассоциативная память, ассоциативный массив;
-
Хеширование;
-
Буферизация;
-
memcached
-
и т.д.
Это только не большая часть методов кэширования, более подробно об веб-кэшировании можно прочитать по следующим ссылкам:
Почему WordPress?
Почему в данной статье рассматривается кэширование для движка сайтов WordPress?
Ну, прежде всего, на сегодняшний день WordPress является самым распространенным движком блогов (и не только блогов). WordPress уже давно перерос с простого блогового движка в портальный движок, в сети уже можно встретить сайты, сделанные на данном движке, от социальных сетей до новостных порталов. Предоставляемый WordPress’ом богатый функционал и множество дополнений (в виде плагинов) подразумевает большое потребление ресурсов (с каждой версией потребление ресурсов увеличивается). Однако, именно богатый функционал и легкость в освоении, а также возможность использования его для различных задач, сделали данный движок одним из самых популярных.
Кэширование в WordPress
Разработчики WordPress предусмотрели возможность использования кэширования и обернули большинство функций движка в буферизованный вывод. В WordPress можно кэшировать практически все, как на уровне объектов (механизм WP Object Cache), так и на уровне страниц (расширенный механизм кэширования). Более подробно о методах и способах кэширования в WordPress, можно прочитать в статье maxsite.org - Кэширование в WordPress.
Данные механизмы кэширования производят сессионное кэширование (то есть, кэширование во время выполнения скрипта) и не дают возможность долговременного кэширования. Однако вы можете написать свой скрипт (плагин) для долговременного хранения кэша в связке со стандартным механизмом кэширования WordPress или использовать один из плагинов кэширования.
Краткий обзор плагинов кэширования:
WP Super Cache - на сегодняшний день один из самых распространенных плагинов кэширования. Плагин WP Super Кэш генерирует статические HTML файлы, которые обрабатываются непосредственно сервером Apache. С помощью этого плагина вы можете существенно ускорить ваш блог WordPress (пояснение автора и других веб-мастеров использующих данный плагин).
На основании высказываний автора плагина и других вебмастеров, использующих плагин WP Super Cache, (после кэширования WordPress’а плагином в HTML обрабатывается непосредственно Apache) можно сделать вывод, что после кэширования страниц WordPress’а плагином WP Super Cache, в следующем запросе веб страницы, плагин выдаст готовые страницы из своего КЭШа, не загружая громоздкий движок (в обход движка). По идее, это должно дать увеличение производительности на 100%. То есть, налицо будет снижение потребления ресурсов. В среднем: запросы в БД должны уменьшиться до 0 (без кеша 30+ запросов), а потребление памяти до 0,1Mb (без кеша +8,6Mb).
В идеале, обратно с уменьшением числа запросов в базу данных (до 50%), увеличивается потребление памяти и время генерации страниц (?). Особенно непонятно непомерное увеличение нагрузки на процессор (вследствие чего частое зависание), что практически сводит на нет действия плагина по уменьшению запросов в БД (подробности смотрим ниже).
Hyper Cache – Принцип работы практически одинаков с WP Super Cache. Тоже создание статических страниц, их хранение и выдача при обращении к сайту.
Недостатки:- много памяти под кэш страницы;- непонятная обработка страницы 404 и укладка в кэш;
WP File Cache – Интересный плагин кэширования для WordPress.
Основные преимущества плагина:
- полная совместимость с интерфейсом класса WordPress Object Cache;- реализация долговременного кэширования на уровне запросов;- сессионное кэширование часто изменяющихся объектов;- использование памяти под сессионный кэш для увеличения производительности;- и т.д.
Это малая часть плагинов. Есть еще много плагинов кэширования WordPress, со своими плюсами и минусами, которые можно скачать на офф сайте (по ссылке - wordpress.org/extend/plugins/tags/cache) и протестировать.
Тест плагинов кэширования.
WP Super Cache – после тестирования плагина выявлено несколько недостатков:
- достаточно сложный в настройке плагин;
- требует достаточно большое дисковое пространство для хранения данных кэширования;- имеются не устраненные программные ошибки, которые часто приводят к “падению” сервера, подробности прочитать можно здесь - WP Super Cache и высокая нагрузка;
- так же, как было сказано ранее, увеличение нагрузки на процессор, об этом, и вообще, об использовании данного плагина, читайте в следующей статье - WP SuperCache и высокая нагрузка, часть 2, Стоит ли овчинка выделки?
WP File Cache – данный плагин рассмотрим более детально, но, не углубляясь в технические вопросы, так как нас в основном интересует именно результат работы плагина.
Итак, результаты теста плагина WP File Cache:
1. Сайт для теста: WordPress 2.5.1, тема магазинная, с включенными платинами (5-6 плагинов).
Потребление ресурсов без плагина WP File Cache:
![]() |
![]() |
Усредненное время рендеринга для главной страницы: 1.415 секунды (43.8% на запросы). DB запросы: 52, Память: 8.55MB.
2. Результаты теста для плагина WP File Cache.
Старт кэширования, плагин WP File Cache,

Время рендеринга: 3.526 секунды (14.8% на запросы). DB запросы: 52, Память: 8.63MB

Итак, после активации и настройки плагина, загружаем главную страницу сайта и смотрим результаты работы плагина. Из представленного скриптоша видно увеличение расхода памяти (0,08, это естественно и немного) и увеличение времени генерации (на 2,1с. Вот это не совсем понятно почти на 200%) страницы. Но, не это меня больше всего удивило, а количество файлов в хранилище кэша, файлов 231 в 14 папках (конечно, некоторые файлы могут использоваться для генерации и других страниц). Но, по-моему, такое количество файлов кэша для одной страницы много. Ведь обработка такого количества файлов, сводит на нет работу плагина. Почему? Все просто, (не вдаваясь в технические подробности) время на загрузку и обработку файла или обращения в базу данных, не сильно разнятся. В принципе, база данных тоже хранит свои данные в файлах и поэтому, обработка большого количества файлов не даст прирост в производительности сайта (а если у вас еще медленная файловая система, то падение производительности будет очень ощутимо)
Обновление кеша

Следующий момент, обновление кэша. В принципе, обновление должно происходить быстрее, так как основная работа по кэшированию страницы была произведена при старте (при первом кэшировании страницы). В идеале получается, наоборот, времени затрачивается намного больше, чем при первом старте.
Работа кэша, выдача кэшированной страницы плагином WP File Cache.
![]() |
![]() |
При выдаче кэшированной страницы радует уменьшение количество запросов в БД более чем на 50%. При этом, расход памяти и время генерации все равно остаются высокими по отношению к расходам без плагина.
Выводы:
Конечно, тут мы подошли к тестированию и выбору плагина со стороны простого обывателя (пользователя). Может, некоторые рассуждения, приведенные в данной статье, не совсем правильные и могут вызвать смех со стороны специалистов. Однако простому пользователю как-то до лампочки все технические вопросы кэширования (и поэтому, в начале статьи был дан материал по кэшированию), ускорения и уменьшения расходов его блога /сайта. И еще момент: большинство плагинов рассчитаны на специалистов, которые имеют (хостятся) свои сервера, а большая часть пользователей хостится на обычных хостингах, где есть лимит на процессорное время. Установка плагина, допустим WP Super Cache, на обычный хостинг, приведет к немедленному отказу в обслуживании вашего сайта со стороны хостинг компании. (Из личного опыта, после установки плагина WP Super Cache на сайт с посещаемостью более 1к и просмотрами более 3к, хостер любезно попросили переехать).
Но все же, обычным пользователям, посоветовал бы плагин WP File Cache, так как он имеет простую настройку, и является самым стабильным плагином.
PS. И, напоследок, поиск плагина кэширования для WordPress не дал результатов, а проблема с сайтом требовала решения. Имея небольшой опыт программирования, я нашел свое решение по уменьшению расходов ресурсов и ускорению работы сайта на WordPress. Это - модуль (плагин) Просто Кэш, о котором расскажу в следующем посту, а вот скриптош работы плагина, покажу (смотрим поле «после» «БД – 0 запросов, Расход памяти 0,14Mb, Время генерации 0,001с» и сравниваем с полем «до» работа сайта без этого модуля).





16.09.2009 в 10:32
Вся штука с кэшированием сводится к тому, что либо кэш нужно размещать в памяти, либо должна быть хорошая подсистема дискового ввода/вывода.
При использовании WP FileCache кэш нужно размещать где-нибудь в /dev/shm (или в RAM Disk для Windows), чтобы не напрягать дисковую подсистему. В принципе, то же касается и Super Cache — особенно при использовании виртуальных серверов — интенсивное использование диска ведёт к повышению iowait (т.е. процессор ждёт окончания ввода/вывода вместо того, чтобы заниматься чем-то полезным), что негативно сказывается на отклике.
16.09.2009 в 12:21
“модуль (плагин) Просто Кэш, о котором расскажу в следующем посту”
Что-то я такого и не нашел…
“БД – 0 запросов, Расход памяти 0,14Mb, Время генерации 0,001с”
Так не бывает
Когда следующий пост будет с описанем?
16.09.2009 в 17:18
Vladimir - абсолютно с Вами согласен, но данное решения для меня не подходить, может в обозримом будущем, когда у меня будет свой сервер и я смогу управлять его начинкой то да.
Евгений - сегодня уже не успею, завтра к вечеру, если успею утром отдать статью редактору.
17.09.2009 в 16:38
продолжение Плагин полностраничного кэширования «Просто Кэш»
17.09.2009 в 21:56
WpTj, такой вопрос: Вы под Windows тестировали? У меня просто есть новая версия плагина (использующая eAccelerator, APC, xCache, ZendFarmework — в зависимости от того, что доступно), но под Windows она имеет мало смысла (из-за кривых портов акселераторов). Если есть желание, могу дать.
И пару слов по статье:
Зависание там по другой причине: гонки при использовании синхронизации. Это может случиться при любой нагрузке. А нагрузка идёт не столько на процессор, сколько на дисковую подсистему. При использовании виртуального сервера или десктопного/медленного железа это очень критично: процессор начинает тратить время на ожидание завершения ввода/вывода, из-за чего замедляется отклик. А так как на серверах Апач обычно использует prefork-модель, замедление скорости обработки запроса приводит к тому, что Апач начинает плодить новые процессы, потребляя память и процессорное время (если есть возможность, протестируйте на сервере, где PHP работает как FastCGI, а не модуль Apache). И хотя снижается нагрузка на MySQL, система себя лучше не чувствует.
Экспериментально я пришел к выводу, что при кэширующие плагины работают нормально только в том случае, если используется серверное железо либо хотя бы быстрые жесткие диски в RAID-маасиве. В противном случае нагрузка с базы переносится на дисковую подсистему. Как-то так.
19.09.2009 в 03:27
Vladimir - большое спасибо за разъяснения (примерно так и думал, но был неуверен) (Апач начинает плодить новые процессы – не знал спасибо), а вообще только вникаю в суть серверного железа
.
Да под Windows (локально) тестировал, и за не имения своего сервера, сейчас устанавливаю пингвинов посмотрим результаты, у чту ваше замечания (FastCG), но думаю результаты не сильно будут разнится (?).
Думаю хорошая идея про RAM Disk, нужно попробыват запустить Денвер с RAM Disk.
25.09.2009 в 17:23
Огромное Вам спасибо за информативный материал. Такого сейчас очень мало.
26.09.2009 в 13:25
Продолжение мне больше понравилось.
20.11.2009 в 13:51
[…] Эффективность плагинов кэширования Wordpress - Кэширование: Разгоняем Wordpress, тест плагинов кэшировани… […]
22.06.2011 в 21:38
У меня вроде побыстрее стало (сайты на линукс).