ГлавнаяРазноеОсновы кэширования в WordPress

Основы кэширования в WordPress

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

Что такое кэш?

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

  • Запрос нашего последнего сообщения из сети Twitter
  • Запрос и вывод погоды со стороннего сервиса
  • Запрос последних записей из базы данных
  • Запрос названия сайта из базы данных

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

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

Кэширование в WordPress

В WordPress существует три основных типа кэширования:

  • Кэширование страниц — позволяет сохранять страницы целиком в кэш, и выдавать их из кэша при последующих запросах
  • Кэширование объектов — позволяет кэшировать данные произвольного типа
  • Транзитное кэширование — очень похоже на кэширование объектов, позволяет сохранять данные на определённый промежуток времени

Все три вида кэширования пересекаются или зависят друг от друга при определённых обстоятельствах. О каждом виде мы расскажем подробнее, начав с самого простого и распространённого.

Кэширование страниц в WordPress

Для выдачи одной страницы архива WordPress приходится проделывать немало работы. Это несколько запросов в базу данных, для того чтобы получить последние записи, настройки виджетов, настройки темы, активные плагины, название и описание сайта, фоновое изображение, заголовок и многое, многое другое.

Кэширование страниц (page cache) позволяет сохранить результат выдачи всей страницы целиком. При последующем запросе по этому же адресу выдаётся эта же страница, но уже из кэша, соответственно гораздо быстрее и с меньшей нагрузкой на сервер.

При изменении содержания записи или странцы, кэш страницы сбрасывается, и при последующем запросе кэшируется уже новая страница с обновлёнными данными.

В самом ядре WordPress кэширование страниц не реализовано, но есть все необходимые функции для реализации этого на уровне плагинов. Два самых популярных плагина для кэширования страниц — WP Super Cache и W3 Total Cache, хотя существуют и другие.

Плагин WP Super Cache

WP Super Cache — самый популярный плагин для кэширования страниц в WordPress. Он позволяет создавать и выдавать статические HTML файлы для ваших страниц, а при определённой конфигурации, вы можете настрить выдачу этих страниц напрямую вашим веб-сервером (Apache или nginx), минуя при этом обработку PHP файлов в целом.

Настройка плагина WP Super Cache

Настройка плагина WP Super Cache

Новые версии плагина WP Super Cache имеют некотоыре дополнительные функции, например настройку CDN, поддержку мобильной версии сайта и прочее, но основая суть данного плагина — кэширование страниц.

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

Плагин W3 Total Cache

Плагин W3 Total Cache более молодой, чем WP Super Cache, но не уступает ему по функционалу. Он очень быстро набирает популярность, и на сегодняшний день насчитывает более 2 миллионов скачиваний из директории WordPress.org.

Плагин W3 Total Cache

Плагин W3 Total Cache

W3 Total Cache позволяет хранить закэшированные страницы как на жёстком диске, так и в памяти. Он не сохраняет структуру кэша, как делает это WP Super Cache, поэтому настроить выдачу без использования PHP невозможно, но в отличии от WP Super Cache использование внешнего хранилища позволяет легко работать в многосерверной архитектуре.

W3 Total Cache имеет огромное количество настроек и дополнительного функционала, включая поддержку CDN, кэширование запросов в базу данных, сжатие скриптов и стилей и многое другое. Мы рекомендуем W3 Total Cache для более опытных пользователей WordPress.

Плагин Batcache

На момент написания данной статьи, плагин Batcache скачали всего около десяти тысяч раз из директории WordPress.org, но в данном случае это не является показателем его эффективности. По производительности он не уступает ни WP Super Cache, ни W3 Total Cache.

Плагин Batcache

Плагин Batcache

У плагина Batcache функция всего одна — кэширование страниц, но делает он это безупречно. Batcache использует внешнее кэширование объектов для хранения данных, что позволяет легко его исопльзовать в многосерверной архитектуре. Этот плагин используется в крупной сети WordPress.com, с более 40 млн сайтов, более 2000 серверов и более 10 млрд просмотренных страниц каждый месяц.

Мы рекомендуем плагин Batcache только для профессиональных разработчиков WordPress, поскольку данный плагин не имеет даже страницы с настройками. Вся конфигурация Batcache происходит в файле PHP.

Какой из плагинов кэширования страниц выбрать вам зависит от размера вашего сайта, от возможностей вашего хостинг-провайдера и от вашего опыта работы с WordPress. Если вы не используете плагинов кэширования страниц на данный момент, мы всегда советуем начать с WP Super Cache. Если вам важно иметь больше возможностией и более тонкую конфигурацию кэширования, попробуйте W3 Total Cache. Если вы неплохо разбираетесь в программировании и серверном администрировании, и готовы пожертвовать графическим интерфейсом при настройке — попробуйте Batcache.

Кэширование объектов в WordPress

Объектное кэширование (object cache) реализовано в самом ядре WordPress. Этот механизм позволяет хранить объекты произвольного типа в памяти и полезен в основном разработчикам тем и плагинов для WordPress.

Например, при запросе опции из базы данных MySQL с помощью функции get_option, WordPress сохранит результат этой функции в памяти, и при последующем подобном обращении выдаст результат из памяти, не делая при этом запросов в базу данных.

Подобное кэширование в ядре реализовано для многих объектов, в том числе: опции, записи (страницы, и произвольные типы), мета-данные записей, термины и таксономии. Именно поэтому, разработчикам WordPress не следует боятся пользоваться такими функциями как get_option и get_post, т.к. подобные обращения не вызывают лишних запросов в базу данных.

Кэширование объектов в WordPress производится с помощью ряда внутренних функций, в том числе: wp_cache_add, wp_cache_set, wp_cache_get.

Постоянное кэширование объектов

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

На первый взгляд это совершенно не выгодно, но если посчитать сколько раз WordPress вызывает функцию get_option для обработки одного запроса (около 500 раз), то выгода от кэширования объектов становится очевидной.

Тем не менее, постоянное кэширование объектов (или внешнее кэшированое) в WordPress легко реализуется с помощью сторонних плагинов, например Memcached Object Cache или APC Object Cache. Оба плагина позволяют использовать оперативную память сервера для хранения объектов WordPress, при этом объекты не пропадают при окончании запроса. Такой подход существенно снижает нагрузку на базу данных MySQL.

Стоит так же отметить, что при включённом кэшировании страниц, до работы с сохранёнными объектами чаще всего время так и не доходит, поскольку страница целиком выдаётся из кэша. Это не является поводом для отключения кэширования объектов, особенно при работе с пользователями которые выполнили вход, а некоторые плагины (например Batcache) вообще используют кэширование объектов для хранения страниц.

Транзитное кэширование в WordPress

Для пользователей данный метод кэширования совершенно прозрачен. Транзитное кэширование (transient cache) позволяет разработчикам сохранять данные на определённый промежуток времени. Этот метод реализован в WordPress с помощью функций get_transient, set_transient и delete_transient.

Транзитное кэширование чаще всего используется для хранения фрагментов, особенно когда речь идёт о запросах на внешние ресурсы, например для вывода сообщения из сети Twitter или для вывода прогноза погоды со стороннего сервиса.

Подобное кэширование так же используется в ядре при работе с RSS лентами, и запросами на обновление тем, плагинов и ядра WordPress.

В отличии от кэширования объектов, транзитное кэширование является постоянным по умолчанию в WordPress, и хранит все данные в базе данных. Но важно отметить, что при использовании плагина для внешнего кэширования объектов (например Memcached или APC), транзитное кэширование будет пользоваться этим плагином для хранения данных.

Кэширование объектов или транзитное кэширование?

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

При использовании плагина для постоянного кэширования объектов, все три метода будут пользоваться этим плагином.

Заключение

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

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

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

И наконец, помните, что кэширование — это всего один из способов повысить скорость вашего сайта. Если скорость для вас важна, не забывайте об оптимизации изображений, сжатии скриптов и стилей, оптимизации запросов и базы данных, использование CDN серверов и распределение нагрузки.

Если у вас возникли вопросы по кэшированию в WordPress или проблемы с настройкой какого-либо плагина для кэширования, оставьте комментарий и мы с радостью вам поможем.

Подписаться на рассылку

Подписаться → Подпишитесь на бесплатную рассылку журнала WP Magazine и получайте новости, события, подборки тем и плагинов, уроки, советы и многое другое в мире WordPress!

  • Добрый день. Как всегда, спасибо за статью. Уже не раз убеждался, что здесь только проверенная полезная информация. Поделился ее везде, где только можно.
    Когда только сделал свой сайт, поставил WP Super Cache. В опциях везде выставил Recommended. Мало того, что сайт, как мне показалось, стал грузиться чуть дольше. Так многие на него еще и не могли зайти. Наверное, из-за того, что поставил mod_rewrite. Как считаете?
    У меня посещаемость около 50-и человек в сутки. Стоит ли устанавливать какой-нибудь плагин для кэша, если пока нагрузка на сервер небольшая?
    И еще одни вопрос. Как узнать скорость загрузки страницы до установки плагина? После установки, ее можно увидеть, если просмотреть код страницы.
    Заранее спасибо.

    • Владимир, спасибо за добрые слова! Если ваш хостинг-провайдер поддерживает Apache вместе с mod_rewrite через .htaccess, то WP Super Cache должен хорошо работать с подобной настройкой. На некоторых хостинг-провайдерах нужно использовать PHP для выдачи закэшированных страни, а не mod_rewrite. Попробуйте изменить настройки и посмотреть как это повлияет на скорость выдачи.

      Учтите так же, что по умолчанию WP Super Cache не кэширует страницы для пользователей, которые выполнили вход, так что при проверки обязательно выйдите из системы, и затем откройте главную страницу.

      Вы упомянули, что многие не смогли зайти на сайт, когда вы установили WP Super Cache. Можете описать подробнее, какую ошибку они получали при заходе на сайт?

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

      Скорость загрузки вы можете узнать с помощью таких инструментов как Google PageSpeed, Yslow, ab и мой любимый loader.io.

  • Константин, вот что выдавало:
    Forbidden
    You don’t have permission to access /wp-content/cache/supercache/v-zdor.com//index.html.gz
    on this server

    • Владимир, видимо ваш веб-сервер не настроен на выдачу сжатых файлов .gz. Вам необходимо либо включить поддержку .gz файлов в настройках веб-сервера, либо отключить сжатие в .gz в настройках плагина.

  • Владимир, очевидно проблема с правами доступа или со сжатием. Возможное ваш веб-сервер не может выдавать сжатые файлы. Попробуйте отключить сжатие в настройках WP Super cache. Если это не сработает, убедитесь в том, что права на директорию wp-content/cache и все её под-директории разрешают чтение от имени пользователя Apache. Вы можете сделать это самостоятельно, или обратиться в поддержку хостинг-провайдера.

    Если это не поможет, но включите режим PHP вместо mod_rewrite. Это будет немного медленнее, но в любом случае гораздо быстрее чем при отсутствии кэширования страниц.

  • Константин, можете напомнить мне, какой код нужно выставить директории для разрешения чтения. 755?

    • Зависит от того, какие пользвоатель и группа являются владельцами директории и файлов. 755 должно сработать, так как это даёт право на чтение и исполнение всем, плюс право на чтение, запись и исполнение владельцу. Если пользователь под которым запущен Apache совпадает с владельцем директории (например www-data) то права 700 тоже должны подойти.

      • Спасибо большое, Константин. Попробую, наверное, еще раз установить. Если от этого плагина такая польза даже сайтам с маленькой посещаемостью. Выставлю право доступа 700, потом 755. Если возникнут проблемы, напишу в поддержку хостинга.

        • Попробуйте так же отключить сжатие, прежде чем обращаться в тех. поддержку. Успехов вам!

  • А подскажите пожалуйста, какую связку плагинов для кешированя лучше всего использовать?
    Так как некоторые плагины начинают между собой конфликтовать.
    Ну и как минус большинство плагинов начинает сыпать кучу нотисов, при включеном дебаг моде.

    Хотелось бы иметь проверенную связку плагинов для установки на продашкены :)

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

      Те два плагина для кэширования объектов, которые упоминаются в статье (Memcached Object Cache, APC Object Cache) хорошо работают с тремя упомянутыми плагинами для кэширования страниц. Конфликтов между ними мы не наблюдали, если же конечно не активировать их все сразу :)

      Здесь на wpmag.ru на сегодняшний день, мы используем Memcached Object Cache для кэширования объектов, Batcache для кэширования страниц, а так же настроен APC на сервере, для кэширования опт кода PHP (не путать с плагином APC Object Cache для WordPress, которым мы не пользуемся).

  • Костя, как всегда спасибо за статью!

    Я насколько понимаю в W3 Total Cache есть поддержка кеширования объектов, по крайней мере я такую настройку там видел =) И вообще я вот его использовал пару месяцев и у моего блога упали сильно позиции в Яндексе, даже sitemap.xml не открывался адекватно, выключил плагин и все встало на свои места, но позиции в Яндексе пока не вернулись, все еще на 40-50 местах по запросам, в которых был на 3-4.

    Наверное с настройками переусердствовал, нужно было аккуратнее пробовать и по одной настроечке включать и смотре, нужно будет копать глубже я так понимаю =) Напишу пост про этот плагин подробный, глядишь разберусь.

    • Александр, спасибо за комментарий! Действительно в W3 Total Cache есть огромное количество настроек, в том числе и объектный кэш, и кэш запросов в базу данных и многое другое, и все они в той или иной степени зависят от окружающей среды — настройки веб-сервера, базы данных и т.д. Успехов вам с экспериментами и не забудьте скинуть ссылку на статью!

      • На самом деле, поэкспериментировав с WP Super Cache и W3 Total Cache, я понял что на моем Shared-хостинге добиться какого-то прироста от них практически нереально =( Но вот небольшие модификации типа включенного gzip, установки mime типов и expires headers в .htaccess существенно улучшают ситуацию.

        Если соберусь переезжать на VPS и смогу вручную настроить Apache, то заново вернусь к этой проблеме =)

        • Александр, можете подробнее описать почему у вас не получилось включить кэширование страниц? С WP Super Cache это должно работать и на простом shared-хостинге, т.к. ему нужно лишь права на создание файлов в директории wp-content/cache и на изменение .htaccess. С этими минимальными настройками должно всё работать не зависимо от других внешних факторов.

  • Оно все получается включить, но постоянно случаются какие-то конфликты. WP Super Cache работает безукоризненно, но он дает прирост в 0,1 секунды =)

    W3 Total Cache. У меня получилось выяснить одну из проблем при включении кеша браузера – конфликт с моим .htaccess, в котором уже были прописаны такие правила. Я их удалил и подсунул «чистый» .htaccess и W3 Total Cache нормально подсунул туда свои правила.

    Что касается кеша страниц в нем же, при работе disk: enhanced прирост тоже не очень большой, а других модулей на Apache на моем хостинге нету =)

    Но даже с учетом того, что вроде бы включен кеш браузера и он даже дает какой-то прирост (порядка половины секунды) – все равно Google PageSpeed Insights предпочитает думать, что кеш не включен и Expires Headers не работают (https://developers.google.com/speed/pagespeed/insights?hl=ru#url=http_3A_2F_2Fluzlol.me_2F&mobile=false&rule=LeverageBrowserCaching), вот почему происходит ЭТО, я понять уже не могу.

    • Прирост в 0.1 секунды это слишком мало для кэширования страниц, возможно вы измеряете выполнив вход на ваш сайт? При стандартной настройке, страницы не кэшируются для вошедших пользователей. То же самое касается W3 Total Cache и Batcache.

      PageSpeed не знает что такое кэш страниц, и тот кэш о котором идёт речь в PageSpeed это наверняка кэш на уровне браузера (DNS, статика и т.д.) — это важно, но это не кэширование страниц. Для измерения кэширование страниц вам нужно измерить время, за которое ваш сервер выдал ответ на запрос, а не время загрузки страницы (что тоже не маловажно). Советую попробовать утилиту ab.

      • Так точно, знаю что нужно проверять незалогиненым и знаю что нужно выводить значение, а не просто смотреть как открывается, я себе в футер сделал вывод значения функции timer_stop(), нос учетом того, что сайт и без кеширования открывается за 0,9с если хостинг не тупит. То прирост всего на 0,1 это вполне реально =)

        • При правильной настройке у меня WP Super Cache выдавал страницу за 2 мс :) таймером измерять не советую т.к. он в любом случае будет показывать закэшированное время, а не настоящее. Попробуйте утилиту ab.

          • У меня вот только доступа к консоли сервера то нету, как мне ab использовать?

          • Александр, вам не нужен доступ к консоли, вам достаточно установить утилиты Apache на вашем локальном компьютере или виртуальной машине.

          • Туплю, я же могу из своего терминала чужой адрес смотреть. Спасибо! Буду тестировать =)

  • Добрый день!

    Если честно, совсем новичок в wordpress, хочу спросить совета.
    Появилась такая проблема. Мне кажется, что она относится именно к кешированию.
    Внезапно стало так, что все обновления на странице в отдельных рубриках сайта (книги, для детей, дневник) видны только в панели администратора. Собственно на сайте (в любых броузерах) обновления не появляются в этих рубриках.

    При этом на главной странице сайта, в рубрике «последние записи» все обновления появляются у всех пользователей.
    Не подскажите ли, что это вообще такое?

    Из плагинов для кеширования стоит WP Super Cache и DB Cache Reloaded Fix. Версия wordpress —3.6 (теперь понимаю, что поспешила).

    С уважением..

    • Оксана, с обновлением вы не поспешили, а сейчас уже на 3.6.1 пора обновляться. Очевидно проблема в кэшировании страниц. При внесении изменений в записи WP Super Cache не удаляет закэшированные страницы архивов. Попробуйте поставить время очистки кэша в настройках WP Super Cache меньше, например один час, тогда кэш архивов будет обновляться каждый час, и ваши изменения будут видны.

  • Отличный пост! Полностраничное кеширование с подготовленным результатом и отдачей готового результата мимо php просто «взрывает» скорость отклика и уменьшает сильно нагрузку на сервер, это бесспорно. Но на сайтах с часто меняющимися данными или множеством «динамических» блоков, полностарничное кеширование не подходит.

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

    Есть ли плагины для работы с Redis, Cassandra?

    • Спасибо Алекс! Да, с динамическими блоками немного сложнее, и обойти PHP уже не получится. Для такого рода сайтов мы советуем Batcache, который позволяет хранить страницы в кэше объектов, а изменять их «на лету» труда не составит.

      > Есть ли плагины для работы с Redis, Cassandra?

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

  • костя

    wp-config-phpуже бьюсь какой день и не получается запустит плагин, не понятно вроде работает и не работает, пишет главная страница есть в хэше, а смотришь сколько страниц в хэше там 0, что делать не знаю? и еще вопрос если я в файле wp-config-php пропишу define(‘DISABLE_WP_CRON’, true); это тоже вроде как снимает нагрузку, плагин будет работать как надо?

    • Костя, если вы о плагине WP Super Cache, то в разделе содержимое кэша нужно нажать на ссылку, чтобы посмотреть страницы в кэше. Попробуйте зайти на ваш сайт в режиме инкогнито и посмотрите выдаются ли страницы из кэша. Если не уверены — присылайте ссылку, мы подскажем.

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

      Директива DISABLE_WP_CRON существует лишь для того, чтобы запускать планировщик задач WordPress не через сам WordPress, а через системный планировщик задач, например crond.

  • Спасибо за статью. Никак не могу подружить W3 Total Cache с простой, цифровой капчей (ставил Captcha и Math Captcha). Включаю капчу, сразу же читатели начинают жаловаться — «срок действия капчи истек» при попытке отправить комментарий или зарегистрироваться на сайте, хотя в настройках самой капчи установил аж 10 мин. В настройках кеша добавил в Cache exception list: — wp-comments-post.php. Все равно не помогает. Может кто знает верные настройки на этот счет.

    • Я бы посоветовал поискать Captcha которая работает на основе JavaScript. У них меньше вероятность возникновения проблем с плагинами кэширования.

      Или же в Cache exception поставьте саму страницу, на которой отображается капча, а не на которую отправляется ее результат. Например wp-comments-post.php итак никогда не кэшируется, поскольку на эту страницу поступают только POST запросы.

  • А можно как-то не кешировать отдельные страницы? У меня на одной раз в две минуты обновляется текст, мне нужно чтобы оно не кешировалось.

  • matsiden

    Здравствуйте. Спасибо за хорошую статью. Но из неё мне так и не стало ясно, если я использую W3 Total Cache и настроил там кеширование в Memcached, нужно ли мне использовать в довесок Memcached Object Cache? Будет ли W3 Total Cache достаточно? Какую дополнительную пользу я смогу извлечь из Memcached Object Cache ?

  • J Seven

    Подскажите. Если не сохранился бэкап базы данных, но сохранились страницы в кэш, можно ли восстановить посты, переустановив WP и залив папку с кэшем?

  • Андре

    Добрый день,подскажите ,пожалуйста,как WP Super Cache не кешировать выбранные страницы. Woocommerce страницы глючат .

  • Кирилл Абрамов

    Добрый день. Подскажите, поставил Redis из исходников, настроил nginx + php7-fpm + плагин для wordpress. Могу ли я еще воткнуть wp super cache? Или в этом нет смысла? Просто не до конца понимаю, как кеширует редис.

    • Вы пишите «+ плагин для WordPress» – что за плагин? Redis сам по себе ничего не кэширует, это обычный сервис для хранения данных, а как вы им пользуетесь уже зависит от вашей конфигурации WordPress.

      • Кирилл Абрамов

        Плагин Redis Object Cache. Как же не кеширует? Видимо вы не больше меня понимаете, что такое redis

        • Кирилл, еще раз повторю, сам по себе сервер Redis – это обычное хранилище данных, и все зависит от того, как вы его используете.

          В вашем случае плагин для WordPress Redis Object Cache сохраняет объекты WordPress (записи, страницы, пользователи, …) на сервер Redis, чтобы их в будущем можно было оттуда прочитать, но учтите, что страницы (полный HTML) этот плагин не сохраняет, поэтому да, WP Super Cache или любой другой плагин кэширующий страницы целиком будет определенно плюсом.

          Поскольку у вас уже есть сервер Redis, вы можете в нем же сохранять страницы целиком, для чего рекомендую плагин Batcache, который сохраняет страницы в кэше объектов WordPress. Если вы хотите кэшировать страницы но при этом необходимости в кэше объектов у вас нет, то посмотрите плагин для WordPress Redis Page Cache.

  • matsiden

    Приветствую. Погонял данный сайт в Firebug, оказалось, что, в
    среднем, страницы, и эта в частности откликаются секунду или даже больше. Засим вопрос — а стоит ли тогда пользоваться BatCache как вы? http://rgho.st/8HdSbLk7W/image.png

    • Наше среднее время отклика из кэша – 4 мс, в обход кэша страниц 182 мс. А то, что вы наблюдаете – это время ответа от нашего сервера до вашего браузера, на что влияют множество внешних факторов, например географическое расположение сервера (США), наличие HTTPS, состояние и скорость вашей сети, пиринговая сеть между вашим интернет провайдером и нашим и т.д.

      Batcache мы уже не пользуемся, перешли недавно на Redis Page Cache, а пользоваться ли вам Batcache или другим плагином, это уже сами решайте, но при выборе плагина кэширования, измеряйте скорость отклика от PHP до Nginx/Apache, а не от PHP до вашего браузера.

      • matsiden

        Наше среднее время отклика из кэша – 4 мс, в обход кэша страниц 182 мс. А
        то, что вы наблюдаете – это время ответа от нашего сервера до вашего
        браузера, на что влияют множество внешних факторов, например
        географическое расположение сервера (США), наличие HTTPS, состояние и
        скорость вашей сети, пиринговая сеть между вашим интернет провайдером и
        нашим и т.д.

        Свою ошибку понял, спасибо. Раньше думал, что правильнее оценивать Firebug. А не подскажете, как правильно считать время отклика из кеша, время в обход кеша? Или ссылку подкинете, где лучше смотреть на данную тему?

        Batcache мы уже не пользуемся, перешли недавно на Redis Page Cache,
        а пользоваться ли вам Batcache или другим плагином, это уже сами
        решайте, но при выборе плагина кэширования, измеряйте скорость отклика
        от PHP до Nginx/Apache, а не от PHP до вашего браузера.

        Я так понимаю, выбор пал на редис, потому что он в тестах показывает себя шустрее, чем memcached?

        • Где именно смотреть время отклика зависит от вашей настройки. Например с nginx, php-fpm и Redis Page Cache, время отклика можно записывать в логи nginx при помощи переменной $upsteram_response_time.

          Redis выбрали не потому что он быстрее, а потому что он гораздо гибче и интереснее, чем Memcached, например в Redis Page Cache страницам можно присваивать теги и сбрасывать кэш по тегам.

          • matsiden

            Я NGINX + Apache пользуюсь, но суть понял, покопаю в эту сторону, спасибо.
            А насчёт Redis — очень интересно. А есть/будет обзор?

          • Возможно, обещать ничего не будем :)