Результаты поиска по запросу Super Cache
Результаты 1–10 из 10
WordPress: кэширование средствами nginx
Много было сказано про кэширование в WordPress… Сегодня я хочу рассказать о действительно эффективном методе, позволяющем сильно снизить нагрузку.
Метод основан на использовании кэша FastCGI web-сервера nginx.
Идея состоит в генерации статических страниц и отдачи их пользователям, не имеющим cookie комментатора. Зарегистрированным пользователям, а также комментаторам всегда отдаётся свежая страница. Так как читателей, ни разу не оставлявших комментарий, как правило, гораздо больше, чем комментаторов, то подобный использование кэша позволяет значительно снизить нагрузку на WordPress/PHP. Знакомые с принципом работы WP Super Cache заметят, что WPSC использует тот же принцип работы. Далее »
Автор: Vladimir, опубликовано в: nginx, WordPress, комментариев: 61Дек
2010
SJ Object Cache: еще более быстрое объектное кэширование для WordPress
После года тестирования наконец-то вышла первая стабильная версия плагина SJ Object Cache.
SJ Object Cache — альтернатива плагину WP File Cache, поддерживающая APC, eAccelerator, xCache, Zend Disk Cache, Zend Shared Memory Cache, memcache и memcached.
В отличие от WP File Cache, SJ Object Cache ориентирован на VPS/VDS и выделенные сервера.
Далее »
Окт
2010
WP Super Cache vs MaxSite Cache: часть 2
Вторая часть статьи WP Super Cache vs MaxSite Cache.
В предыдущей части я сравнивал поведение MaxSite Cache и WP Super Cache на тестовом VDS (512 MiB RAM, 10 GB HD, Intel Xeon X3320 (1 ядро), 2.5 GHz), на котором ни операционная система, ни программное обеспечение не были специально настроены — бралась конфигурация «из коробки» и тестировалась. Одним словом, «VDS абсолютного чайника».
В этой части изменилась только конфигурация программного обеспечения: сервер настраивался на максимальную производительность.
В частности:
- отказ от Apache в пользу nginx и от
mod_php5в пользуphp-fcgi(количество FastCGI-процессов выбиралось таким образом, чтобы избежать использования файла подкачки); - смена ядра с
linux-image-serverнаlinux-image-virtual; - настройка MySQL: отказ от InnoDB (экономит примерно 100 МБ памяти), увеличение буфера ключей и т.п.;
- установка и настройка xCache (я исходил из того, что далеко не все чувствуют себя комфортно при сборке программ из исходников, поэтому брал только готовое ПО);
- настройка
iptablesдля фильтрации пакетов.
Дек
2009
WP Super Cache vs MaxSite Cache: часть 1
После того, как MAX’у не понравился тест с участием MaxSite Cache, я решил несколько видоизменить методику тестирования.
На этот раз я тестировал только два кэша: WP Super Cache и MaxSite Cache Lite. Далее »
Автор: Vladimir, опубликовано в: WordPress, комментариев: 9Ноя
2009
WP Super Cache vs HyperCache vs W3 Total Cache vs MaxSite Cache
Для WordPress написано много кэширующих плагинов, предназначенных для борьбы со слабой производительностью сервера (либо кривыми руками администратора, который не в состоянии настроить PHP/MySQL). Простой пользователь зачастую задаётся вопросом: какой же из плагинов выбрать?
В данной статье я рассмотрю наиболее популярные плагины (WP Super Cache, Hyper Cache, W3 Total Cache и MaxSite Cache), а затем расскажу о результатах жестокого теста, которому я подверг все эти плагины. Далее »
Автор: Vladimir, опубликовано в: WordPress, комментариев: 53Ноя
2009
WP Super Cache и высокая нагрузка: часть 2
Вчера я наконец-то поднял munin и новый monit на сервере, а сегодня посмотрел на результаты мониторинга. Самое первое, что бросилось в глаза: iostat показывает очень большое количество записей (превышавшее количество чтений почти в тысячу раз).
На сервере живут четыре сайта на WordPress, два из которых (littlefox.ru и cat-tv.ru) находятся в Alexa Top 100,000 (они создают основную нагрузку на сервер).
Особенность обоих сайтов — они используют небезызвестный плагин WP Super Cache. Мне с этим плагином приходилось неоднократно сталкиваться, и не всегда с хорошей стороны (так получилось), так что я имею представление о том, как он работает.
С целью поэкспериментировать мы отключили WP Super Cache. В результате получилась такая картина. Далее »
Автор: Vladimir, опубликовано в: WordPress, комментариев: 17Июл
2009
WP Super Cache и высокая нагрузка
Проблема: PHP случайным образом перестаёт реагировать на внешние запросы.
Сайт работает на WordPress (с WP Super Cache), web-сервером стоит nginx, php-fpm с 40 дочерними процессами висит в режиме FastCGI. Довольно-таки стандартная конфигурация.
Иногда (периодичность не ясна) сайт падает. В том плане, что nginx выдаёт ошибку 502 Bad Gateway. При этом в логах отображается примерно такое:
Лечится только перезапуском php-fpm. Далее »
Мар
2009
WP Super Cache + nginx: замена правил mod_rewrite
Сборная солянка с нескольких форумов (ссылок, к сожалению, не дам, но Google может помочь); данная конфигурация является рабочей.
Далее »
Фев
2009
WP File Cache: долговременное кэширование в WordPress
Как известно, WordPress поддерживает два вида кэширования:
- Кэширование на уровне страниц;
- Кэширование на уровне запросов.
Кэширование на уровне страниц WordPress поддерживает, но самостоятельно не реализует, вследствие чего приходится использовать сторонние плагины (Hyper Cache, WP Super Cache и т.д.). При всех достоинствах постраничного кэширования, у него есть несколько недостатков, а именно:
- невозможность использования динамических элементов (например, captcha, работающая по методу «изящного отсеивания спама») или виджетов, генерирующих динамический контент (например, quote of the day);
- плагины, которые отдают комментатору статическую версию страницы (в этом был замечен Hyper Cache), вынуждают пользователя каждый раз вводить свои данные (имя, сайт, email) заново.
Кэширование на уровне запросов WordPress поддерживает и реализует самостоятельно, но в этой реализации есть один недостаток: кэш между сессиями не сохраняется (что может привести к неприятным последствиям). Тем не менее, из-за особенностей архитектуры WordPress, без кэша WordPress работать будет очень медленно.
Очевидно, что если сохранять кэш между сессиями (что WordPress поддерживает, но самостоятельно реализовать не может), это может весьма положительно повлиять на производительность.
Отмечу, что хотя поддержка кэширования на уровне запросов (в том виде, как она реализована сейчас) появилась в версии 2.5, в ядро WordPress были внесены изменения, позволяющие поддерживать долговременное кэширование без танцев с бубнами, только в версии 2.6.
На WordPress.org, как ни странно, плагинов, поддерживающих долговременное кэширование на уровне запросов, я не нашел. Вероятно, разработчики считают, что это экономия на спичках и разумнее будет творить что-то более глобальное (например, страничное кэширование).
Первая версия плагина WP File Cache родилась у меня давно — еще в июне. И лишь недавно я нашел время, чтобы привести плагин в человеческий вид, добавить интерфейс для администратора и перевести плагин на русский язык.
Функциональность плагина:
- реализация долговременного кэширования на уровне запросов;
- полная совместимость с интерфейсом класса
WP_Object_CacheWordPress; - использование памяти под сессионный кэш для увеличения производительности;
- сессионное кэширование часто изменяющихся объектов;
- хранение настроек в коде плагина.
Особенности плагина:
- возможность отключения кэширования (в том числе и встроенного в WordPress);
- возможность отключения межсессионного кэширования;
- возможность задания групп, не подлежащих межсессионному кэшированию (полезно только разработчикам, которые знают, о чём идёт речь);
- плагин хранит свои настройки непосредственно в коде (в файле
wp-content/object-cache.php). Это связано с проблемой курицы и яйца, а также с архитектурными особенностями WordPress: дело в том, что WordPress инициализирует кэш вызовомwp_cache_init(): при обработке данного вызова плагин должен инициализировать кэш. Если бы настройки хранились в таблицеwp_options, плагин бы использовал функциюget_option(). Но функцияget_option()вызываетwp_cache_get(), аwp_cache_get()не может использовать кэш, потому что он не инициализирован. В принципе, это не является проблемой; проблема заключается в том, чтоget_option()читает все опции из таблицы, для которыхautoloadустановлен в 1. На практике это 90–95% таблицы. Ранее я уже писал, что WordPress в целом иget_option()в частности спроектированы так, что если кэширующий модуль не вернул данные, функция затребует их вновь и в полном объеме. Иными словами, опции будут загружены дважды (два обращения к базе данных). А это нехорошо. Поэтому настройки хранятся непосредственно в коде.
Плагин существует в четырёх локализациях: ураинской, русской, английской и белорусской. Если есть желание перевести плагин на другой язык, пишите.
Замечания по установке:
После активации плагин для хранения кэша будет использовать каталог wp-content/plugins/file-cache/cache. Поэтому перед активацией каталог должен быть доступен на запись. Каталог для хранения кэша можно изменить в настройках (для увеличения производительности имеет смысл размещать кэш на RAM-диске); каталог также должен быть доступен на запись.
Плагину при активации/сохранении настроек должен быть доступен на запись каталог wp-content: в него копируется файл object-cache.php. После того, как плагин активирован и сконфигурирован, права на запись можно убрать.
Удаление/деактивация плагина:
Для успешной деактивации каталог wp-content должен быть доступен на запись — требуется удаление файла wp-content/object-cache.php.
Для срочной деактивации плагина можно удалить или переименовать файл wp-content/object-cache.php. В этом случае WordPress будет использовать встроенные механизмы кэширования.
Download
Скачать последнюю версию плагина WP File Cache.
Список изменений
- Версия 1.2.8:
- Добавлена украинская локализация (спасибо Андрею К.).
- Версия 1.2.7:
- Добавлена белорусская локализация (спасибо Antsar);
- Добавлена экспериментальная возможность использовать свежие данные в панели администрирования (данные будут браться из базы данных, кэш при записи будет обновляться).
- Версия 1.2.5:
- Кэшируемые данные больше не передаются по ссылке, что позволяет избежать случайного изменения данных в кэше;
- Кэшируемые объекты перед помещением в кэш клонируются (из тех же соображений).
- Версии 1.2.3–1.2.4:
- Размещение плагина в репозитории WordPress и исправление ошибок, вызванных изменением каталога плагина. Спасибо Raveex за терпение и тестирование.
- Версия 1.2.2:
- Добавлена базовая совместимость с WordPress 3.0.
- Версия 1.2.1:
- Оптимизация кода, ускорение работы кэширующего движка;
- Блокировка файла при записи;
- Использование меньшего количества системных вызовов при записи файлов.
- Версия 1.1
- Версия 1.0
- Версии 0.2.x
Оценки производительности
- «Голый» WordPress 2.7rc1:
- Кэширование запрещено: 191 запроса, 0.587 с
- Встроенный в WordPress кэш: 18 запросов, 0.350 с
- WP File Cache: сессионное кэширование: 18 запросов, 0.334 с
- WP File Cache: долговременное кэширование: 3 запроса, 0.315 с
- Данный сайт:
- Кэширование запрещено: 1442 запроса, 3.558 с
- Встроенный в WordPress кэш: 51 запрос, 0.776 с
- WP File Cache: сессионное кэширование: 51 запрос, 0.615 с
- WP File Cache: долговременное кэширование: 13 запросов, 0.576 с
Дек
2008
Ответ на «13 Тэгов, которые следует удалить из вашей темы»
Сегодня мне наконец-то посчастливилось найти концы (в смысле, оригинал) статьи, которую публикуют многие блоггеры (в переводе на родной язык). Статья носит название «13 Тэгов, которые следует удалить из вашей темы» (с ней можно ознакомиться, например, здесь).
В переводе меня смутило то, что автор, на мой взгляд, «экономил на спичках», вместо того, чтобы использовать что-либо стоящее, поэтому я решил обратиться к оригиналу, в надежде на то, что автор хоть как-нибудь обосновал свою точку зрения. Далее »
Автор: Vladimir, опубликовано в: WordPress, комментариев: 8Июн
2008

Меня зовут Владимир, я программист-фрилансер, специализирующийся на Web-программировании и програмировании под Linux.
По совместительству занимаюсь администрированием LAMP/LNMP-серверов и техническим переводом.

