Почему-то, как мне показалось, довольно тихо прошло появление очередного “всесильного всемогущего сокращающего время загрузки и нагрузку на сервер” плагина WP-Super-Cache, а ведь за бугром о нём только ленивый не писал и даже успели отDiggать страницу плагина почти тысячу раз. Поэтому, думаю, стоит всё же приглядеться и пощупать это чудо программерской мысли.
Итак, что же может этот плагин, для чего/кого он предназначен и чем лучше аналогичных стандартных и не очень средств кэширования?
Введение
Большинству пользователей Wordpress’а известен прекрасный плагин
WP-Cache 2. Он кэширует страницы блога и отдаёт их по запросу без обращения к базе данных. Несмотря на это, всё же приходится подгружать определенный php-код, чтобы обслуживать уже кэшированные страницы, чтобы там не говорили на странице о
wp-cache (прародитель wp-cache2)
WP Super Cache действует по другому принципу. После установки, создаются html файлы, и они отдаются браузеру без единого вызова php. Насколько быстро ваш сервер отдаёт картинки? Почти так же быстро он будет выдавать и кэшированные страницы. Если вашему сайту ежедневно приходится справляться с массированным потоком посетителей или периодически испытывать Дигг-эффект, то этот плагин для вас.
Как оно работает то?
Как обычно действуют люди, подготавливая свой сайт к массовому паломничеству с дигга? Они в ручную сохраняют копию страницы, которая теоретически будет генерить основной траффик, и помещают её в папку соответствующую пермалинку. Этот метод помогает серверу выдерживать большие нагрузки и не “умирать”, но эффективность его напрямую зависит от возможности предсказывать потоки пользовательского интереса к страницам. Сам по себе WP-Cache хоть и полезен, но в определенных ситуациях не совсем адекватен, тогда как WP Super Cache как раз и был создан, чтобы воссоздавать этот процесс автоматически.
Когда к странице обращается незалогиненый посетитель или он не оставляет комментариев, то сервер отдаёт ему статическую html-страницу из подпапки supercache, которая создаётся в cache папке WordPress. Если вы зайдёте в эту папку (например по фтп), то обнаружите точную копию своей пермалинк структуры в виде папок и отдельные html-файлы в каждой из них. Чтобы убедиться, что страница создана плагином, достаточно просмотреть её исходный код и вы обнаружите там следующую строку в самом конце <!– super cache –> или <!– super cache gz –> для сжатого варианта.
Залогиненым же пользователям или тем, кто оставит комментарий, будет показана кэшированная страница, созданная средствами стандартного WP Cache, где в конце будет значится <!– Cached page served by WP-Cache –>.
Фишки/Отличия от WP-Cache
- Собственная система hook’ов, для более тонкой настройки кэширования (важно только разработчикам).
- Прекрасно работает и с WordPress MU в VHOST и не-VHOST конфигурациях. Файлы каждого блога кэшируются независимо друг от друга.
- Стандартные файлы WP-Cache разбиты на 2 части. Мета-файлы теперь располагаются в отдельной папке, что увеличивает скорость обращения к ним и определения необходимости обновления кэша.
- Встроена заплатка для WP-Cache при работе с защищенными постами.
- Автоматически отключает gzip-сжатие в WordPress вместо того, чтобы “умереть”.
- Улучшена работа с Akismet и иными плагинами борьбы со спамом - кэш будет обновлен, только если комментарий 100% не спам.
- Кнопка “lock down” (защёлкнуть) - подготавливает сайт к мощному наплыву посетителей. После включения “защёлкивает” статичные кэш файлы и не удаляет их после добавления нового комментария.
- Автоматическое внесение изменений в .htaccess (Не забудьте сохранить свой .htaccess перед установкой плагина).
- Не кэшируются запросы с GET-параметрами.
- Улучшенная проверка совместимости wp-cache-config.php и advanced-cache.php, если вы пользовались старой версией.
- Улучшена поддержка Microsoft Windows.
- Правильно работает с кэшированными страницами в ОС Red Hat/Cent или других, содержащих запись для gzip в /etc/mime.types.
- Функция “Не кэшировать следующие адреса” теперь может использовать регулярные выражения.
Минусы
- Если вы залогинен или оставили комментарий, вы никогда не увидите super-cache страницу. Вам всегда будет выдаваться старый-добрый WP-Cache. Это не так уж и плохо, так как большинство ваших посетителей никогда не оставляют комментарии.
- Для работы со статическими страницами используется Mod Rewrite Апача, поэтому необходимо, чтобы он был активирован на сервере.
- Особо динамичные части вашего сайта не будут обновляться так быстро, как хотелось бы. Например, виджет - последнии комментарии.
- Некоторые хостинги испытывают проблемы при работе со сжатыми html-файлами, т.ч. может потребоваться дополнительная настройка.
- Не рассчитывайте, что дешевый хостинг выдержит большой всплеск трафика, даже если страницы будут кэшированы.
- Помните, что динамический контент, вроде того, который размещается в сайдбаре, будет обновлен только когда будет обновлена кэшированная страница. Время до обновления можно настроить, но кэшированные файлы будут удалены лишь в том случае, если у вас будет смесь из статических и динамических запросов.
- Некоторые плагины, такие как SK2, Bad Behaviour и другие, работа которых зависит от “свежести” данных, могут работать не совсем корректно, во всяком случае, до тех пор, пока эти плагины не будут специально оптимизированны для очищения кэша в нужный момент.
(с) Автор Плагина
Это всё конечно интересно и красиво на словах, но работает ли оно в действительности? Сам я не мастер нагрузочного тестирования, поэтому приведу выкладки других людей.
Во-первых, автор плагина ставит в пример себя - после анонса Wp-Super-Cache на дигге, посещения скакнули до 4700 пользователей, что прямо скажем не мало. И вот какие графики получились - первый нагрузка на процессор, второй - посещения.
Отчётливо виден момент активации кэширование (падение нагрузки на процессор), а так же приятно наблюдать, что рост посещений никак не сказывается на процессоре.
Во-вторых, некий Роберт провёл замеры производительности для 1000 запросов. Тестировал по локальной сети, на сервере (P4 - 3Ghz, 2GB RAM) поставил чистый ВордПресс и с другой машины делал запросы.
Результаты:
а) стандартный WordPress без кэша:
- время на тест - 161 сек;
- запросов в секунду - 6.21/сек
- время на 1 запрос - 161 мсек
- скорость передачи - 31.07 Kbytes/сек
б) WordPress + Super Cache:
- время на тест - 5.718750 сек;
- запросов в секунду - 174.86/сек
- время на 1 запрос - 5.719 мсек
- скорость передачи - 898.62 Kbytes/сек
в) WordPress + Super Cache + eAccelerator:
- время на тест - 2.531250 сек;
- запросов в секунду - 395.06/сек
- время на 1 запрос - 2.531 мсек
- скорость передачи - 2030.22 Kbytes/сек
Думаю, комментарии излишни.
Включил сейчас плагин на этом блоге, на пару минут для теста активировал gzip-сжатие и проверил, как реагируют браузеры. С Оперой и ФФ всё ок, а ИЕ6 как обычно отличился - предложил сохранить локально .html.gz страничку) Чтобы не пугать людей, сжатие отключил, но вообще нужно будет разобраться почему ИЕ так отреагировал.
Плагин в установке достаточно прост, особенно если следовать рекомендациям в readme :-), а вот настройка для тех, кто не видел до этого Wp-Cache2, возможно покажется непонятной. С другой стороны Wp-Super-Cache довольно специфическая вещь и не факт, что окажется востребованным.
Хотелось бы узнать - нужно ли отдельным постом расписывать установку и настройку?
Кстати, курсовая и 2 из 4 экзамены сданы на отл., что ещё немного приближает ко второму красному диплому :p
Заинтересовался я тут
eAccelerator, интересно, удастся ли мне поставить его на виртуальную площадку у МастерХоста. Если да, то напишу как и что я делал.
Удачного дня и побольше Дигг-эффектов.
