ГлавнаяПлагиныMemcached для кэширования объектов в WordPress

Memcached для кэширования объектов в WordPress

Memcached является одним из самых быстрых и популярных средств для кэширования произвольных данных в оперативной памяти. В этой статье мы рассмотрим установку и настройку сервера Memcached для кэширования объектов в WordPress.

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

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

Memcached

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

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

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

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

Установка Memcached

Для того, чтобы установить сервер Memcached вам потребуется доступ администратора к вашей хостинг-площадки. Большинство провайдеров виртуального хостинга не предоставляют такой возможности, поэтому следует смотреть в сторону виртуальных (VPS) или выделенных (dedicated) серверов. Учтите так же, что на некоторых специализированных хостинг-площадках уже установлен и настроен сервер Memcached, например WP Engine.

Установить сервер Memcached легко с помощью менеджера пакетов в том или ином дистрибутиве Linux. Например в Ubuntu или Debian Linux сделать это можно с помощью утилиты apt-get:

sudo apt-get install memcached

После установки сервер Memcached запустится сразу. Конфигурация сервера находится в файле /etc/memcached.conf, где вы можете настраивать такие параметры как память, адрес и порт. Эти данные вам потребуются при конфигурации плагина для WordPress.

После внесения изменений в конфигурационный файл не забудьте перезагрузить сервер:

sudo service memcached restart

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

Memcached в WordPress

Memcached Object Cache является самым популярным и надежным плагином для кэширования объектов на сервере Memcached. Он написан Райаном Борэном, одним из ведущих разработчиков ядра WordPress.

Для работы данного плагина вам потребуется расширение memcache для PHP, которое можно найти в официальном репозитории PECL. Установить данное расширение можно с помощью команды pecl на вашем сервере:

sudo pecl install memcache

После установки расширения (если pecl не сделает это за вас) вам необходимо будет перезагрузить PHP, чтобы интерпретатор подключил новый модуль.

Установка плагина Memcached Object Cache отличается от установки других — вам не следует размещать плагин в директории wp-content/plugins, поскольку Memcached Object Cache является не типичным плагином, а так называемым дроп-ином (или вкраплением), который выполняется на самом раннем этапе загрузки ядра WordPress, и который не возможно отключить через панель администрирования.

Дроп-ины (или вкрапления) в WordPress

Дроп-ины (или вкрапления) в WordPress

Файл object-cache.php из архива плагина следует разместить в директории wp-content, после чего плагин автоматически становится активным.

Если на данном этапе при посещении вашего сайта вы увидели «белый экран смерти», то причин может быть несколько:

  • Не установлен модуль memcache для PHP
  • Не запущен сервер Memcached
  • Нет доступа к серверу, например он сконфигурирован на другой порт

Конфигурация плагина

Интерфейса для конфигурации плагина Memcached Object Cache нет. Вся конфигурация происходит с помощью PHP файла, например wp-config.php:

define( 'WP_CACHE_KEY_SALT', '' );
$memcached_servers = array( '127.0.0.1:11211' );

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

Глобальный массив $memcached_servers содержит адреса и порты всех серверов Memcached. Если вы используете стандартную конфигурацию, то вероятнее всего данный массив вам объявлять не нужно.

Чтобы отключить кэширование объектов в Memcached достаточно удалить или переименовать файл object-cache.php в директории wp-content. Учтите, что это не удалит данные на сервере. Если вы хотите удалить все данные с сервера, его необходимо перезагрузить или отправить команду flush_all.

Плагин Memcached Redux является альтернативой плагину Memcached Object Cache. Он использует класс Memcached и расширение для PHP memcached (а не memcache), которое так же можно установить из репозитория PECL.

Статистика Memcached

К серверу Memcached можно подключиться с помощью утилиты telnet и посмотреть статистику с помощью команды stats:

telnet 127.0.0.1 11211
stats
STAT pid 7794
STAT uptime 3084
STAT time 1395221340
STAT version 1.4.13
...

Данная статистика позволит вам узнать эффективность кэширования объектов и потребляемую память. Самыми важными значениями здесь являются get_hits и get_misses которые означают наличие или отсутствие объекта в кэше при запросе. Если значение get_misses не намного меньше чем get_hits, то возможно вам необходимо увеличить выделяемую память серверу Memcached.

Статистика сервера Memcached

Статистика сервера Memcached

Статистику использования кэша объектов в WordPress можно посмотреть с помощью плагина Debug Bar, а если вы предпочитаете графическое представление статистики Memcached, вы можете попробовать скрипт memcache.php.

Безопасность

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

Это значит, что Memcached следует использовать только в закрытых и защищенных сетях.

В Memcached так же нет пользователей и привилегий, поэтому если вы используете один сервер для двух разных сайтов, один сайт может легко получить доступ к данным другого сайта, независимо от уникальных префиксов.

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

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

  • Алексей Мотовилов

    Спасибо!

  • Anatoly Yumashev

    Давно я ждал эту тему :)

    И я таки думал что это делается через Batcache.

    В чем преимущества Batcache относительно Memcached Object Cache?

    • Batcache и Memcached Object Cache немного разные вещи. Memcached Object Cache реализует постоянное кэширование объектов с помощью сервера Memcached. Batcache это плагин для кэширования страниц, который использует кэширование объектов для хранения данных.

      Иными словами Batcache отлично работает в паре с плагином Memcached Object Cache, но построен он таким образом, что работать сможет с любым другим плагином для внешнего кэша объектов, например WordPress Redis Backend или APC Object Cache.

  • Всегда хотелось узнать что же такое «крупных высоко-посещаемых проектах». А то везде пишут на словах, а сколько это примерно в цифрах непонятно. У всех много и высоко разное.

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

      На личном опыте, мы совсем недавно работали со стэком в 5 веб-серверов, которые обрабатывали ~ 200-300 запросов в секунду на пиках.

    • Кеширование необходимо делать независимо от посещаемости, оно очень хорошо снижает нагрузку на сервер и ускоряет сайт. OPcache (модуль PHP) для кеширования компилированых скриптов, Memcahed для объектного кеширования, использование функций wp_cache_* для сохранения кусков страниц в том же Memcached и Batcache для кеширования страниц целиком — и сайт летает. Если это еще на Nginx и нормально настроено — вообще праздник)

    • Ура. Я взял себе VPS. С кэшированием и правда стало полегче, а с Batcache в режиме инкогнито сайт как буд-то вообще с локального сервера открывается. Отдается за 0.003 секунды.

  • Par Example

    Если на одном сервере, скажем 2 и более сайта, то значит использование memcached не оправдано. Я так понял.
    Если возможно расскажите подробнее про «…если вы используете один сервер для двух разных сайтов, один сайт может легко получить доступ к данным другого сайта, независимо от уникальных префиксов.»
    — к БД через мемкешед ?

    «…Вся конфигурация происходит с помощью PHP файла, например wp-config.php»
    — этого не достаточно для разделения данных?

    • Если оба сайта принадлежат вам, то проблем никаких не будет. Вы можете использовать сервер Memcached для сотни сайтов на одном сервере, достаточно лишь разделять ключи, например с помощью константы WP_CACHE_KEY_SALT в конфиге.

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

  • Par Example

    Memcached и APC2.0.6 имеют одно название файла и располагаются в одной директории. Если на сервере установлены и APC, и Memcached то чему отдать предпочтение? Параллельное использование возможно?

    • Если речь об object-cache.php, то вам нужно выбрать и использовать один плагин. Если вы хотите кэшировать объекты WordPress на сервере Memcached, то используете object-cache.php от плагина Memcached. Если APC то APC. Если вы хотите использовать APC (или другой акселератор) для кэширования байт-кода PHP рядом с Memcached для объектов WordPress, то object-cache.php от Memcached, а кэширование байт-кода в любом случае прописывается в php.ini.

  • Пара «вопросов» при настройке появилась :)

    WP_CACHE_KEY_SALT устанавливать любой? Я поставил korobochkin_, например, по аналогии с базами данных.

    Для мультисайта, как я понял, WP_CACHE_KEY_SALT все равно один раз указывается.

    Теперь вот надо учиться делать бэкапы Debian, чтобы не весь образ (всю систему) сливать, а только то, что надо. И в архивчик.

    • Да, соль можно указать любую, она нужна в том случае если на одном сервере Memcached у вас крутится два и более сайта, по аналогии с $table_prefix для MySQL. Для резервных копий попробуйте mysqldump и tar, можно по расписанию через cron.

      • Я про резервное копирование конфигурации сервера (не сайтов). С сайтами более-менее все ясно, хотя я делал через grunt https://gist.github.com/korobochkin/3e558d4155ed1a94754a чтобы не весь public_html бекапить, а лишь uploads и список установленных плагинов и тем в каком-нибудь json формате. Но судя по скриншоту в статье можно не париться, а весь public_html в архив засовывать.

        • Если вы уже используете Git или Subversion для кода, то в этот же репозиторий можно и конфиги записать. Очень удобно, особенно если используется более одного сервера, например:

          /home/wpmag/.config/web/nginx.conf
          /home/wpmag/.config/web/php.conf
          /home/wpmag/.config/lb/nginx.conf
          /home/wpmag/.config/db/mysql.conf

          • Интересно. А как это все использовать? По списку видно, что файлы-конфиги лежат в домашней директории пользователя wpmag. А сами же конфиги серверов расположены в /etc/ (у меня Debian), причем там очень много файлов, сходу так разобраться какие нужны, а какие нет сложно.
            Плюс на сервере стоит некий список софта, который в случае аварии надо будет поставить — ручками? Или какой-то sh-скрипт?
            И у меня Apache и каждый сайт запускается от своего www-user во избежания конфликтов между сайтами и чтобы с одного сайта другой попортить нельзя было :) Т. е. юзеров тоже надо таскать за собой.

          • Во многих приложениях можно подключать дополнительные конфигурации через директивы типа include path/to/*.conf, или же можно при деполе делать символическую ссылку (если ее еще нет) с /etc/nginx.conf на /path/to/.config/web/nginx.conf, вариантов много.

            По поводу софта это уже больше в сторону менеджеров конфигураций и пакетов, типа Chef, Puppet, SaltStack и т.д., некоторые также умеют работать с пользователями. Ну и наконец можно всегда самостоятельно написать серию скриптов, например с помощью Fabric, которые на основе какого-нибудь конфига или JSON массива, будут создавать пользвоателей.

          • А никаких побочных эффектов не будет от использования ссылок? Например я заметил, что если делаю плагин под WordPress и использую ссылку для папки плагина (например ставлю ссылку из моей Dropbox-папки в директорию с сайтом), то переменная _ _ FILE _ _ в PHP отдает путь, в котором папка Dropbox, а не та, что на сервере. Итого у меня не работают activation и deactivation hook. Вот, кстати, тоже вопрос, как разрабатывать темы и плагины, чтобы физически оно в Dropbox лежало, но и на локальный сайт постоянно не приходилось копировать файлы руками.

          • Нет, для конфигов побочных эффектов не будет, они сами часто пользуются символическими ссылками, например nginx/sites-enabled в nginx/sites-available, или php/fpm/conf.d и php/conf.d и т.д. С плагинами в WordPress да, была такая проблема, которую в 3.9 вроде устранили, так что попробуйте еще раз.

  • Добрый день. Для memcached разве не требуется php5-memcached (или Php5-memcache)?

    • Требуется, правда на многих хостинг-площадках эти пакеты уже предустановлены.

  • Кирилл

    Добрый день! Отличная статья, но, блин, все выполнил, дошел до плагина, и как вы писали, белый экран смерти! Хотя все, повторю, установил! Как включить memcached на ubuntu 14 ?

    • sudo service memcached start на Дебиане, наверное и в убунте также :)

    • Белый экран вероятно из-за отсутствия требуемого модуля для PHP. Посмотрите лог ошибок, наверняка там что-нибудь вроде undefined class Memcached.

      • Кирилл

        Да, все верно! Спасибо! Подключил, посмотрим как скажется на скорости..))