Кэширование в 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/
Архив работы
- . Низкие цены, газоблоки оптом и в розницу газоблок Киев.
- Магазины керама марацци. Керама марацци аллигатор.