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

Пост написан от лица WordPress-разработчика Райана Хэллайера.

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

Кэширование статичных страниц

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

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

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

По умолчанию WordPress включает в себя внутреннюю систему кэширования. Если вы используете get_option( ‘something’ ); где-либо на вашем сайте, и затем запустите этот же код позже на той же самой странице, WordPress загрузит эти данные из БД только один раз, после чего они будут уже кэшированы для последующего использования на данной странице. Делается это через функции wp_cache_add(), wp_cache_set() и wp_cache_get().

Transients ведут себя похожим образом, однако по умолчанию могут хранить данные для использования при последующих просмотрах страницы; эти данные сохраняются в БД. Хранение информации в БД, однако, сильно съедает ресурсы, поэтому transients должны использоваться экономно, чтобы избежать забивания базы данных и замедления работы сайта вместо его ускорения.

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

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

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

Обычный WordPress плагин не может использоваться для реализации постоянного кэширования объектов в WordPress. Вам нужно вручную создать файл object-cache.php, который размещается в папке wp-content. Некоторые мощные плагины будут автоматически генерировать этот файл в вашей папке wp-content.

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

Некоторые ранние реализации файлов object-cache.php для WordPress просто сохраняли данные в БД либо в однородные статичные файлы. Однако вообще есть много лучших бэкэндов/мест, где можно хранить небольшие части данных, и есть много разных дроп-инов для кэширования объектов, которые доступны для WordPress, и их можно подцепить к этим разным системам.

Хранение данных в памяти

MySQL быстр, однако ничего не выдерживает сравнения с простым внесением некоторых данных в RAM для максимальной производительности. Учитывая это, многие люди, которые гораздо умнее меня, разработали системы, позволяющие вам хранить произвольные куски данных в памяти сервера. Самое популярное решение для этого – Memcached, однако есть и другие решения, среди которых можно назвать APC и Redis, которые известны сегодня. Поскольку они хранят свои данные в памяти (когда это возможно), и разработаны с учетом быстроты, а не надежности, они очень быстро производят и хранение данных, и их извлечение.

Используя базу данных или flat-файл для кэширования, вы не можете быстро обновлять свой кэш или хранить небольшие куски данных. С помощью хранения данных в памяти можно быстро решить эту проблему. По этой причине использование хранения данных в памяти может привести к заметному увеличению производительности для сайтов, используя соответствующие бэкэнды вместе с WordPress API для кэширования объектов.

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

• Memcached – https://wordpress.org/plugins/memcached/
• Redis – https://wordpress.org/plugins/wp-redis/
• APC – https://wordpress.org/plugins/apc/

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

Очень часто можно видеть, как число MySQL-запросов снижается от 20+ до 4 запросов на страницу, поскольку бэкэнд кэширования объектов заботится о хранении всех данных, которые не меняются между загрузками страницы. WordPress API всегда пытается обновить кэш при необходимости; существуют некоторые экземпляры, для которых это не всегда работает идеально, однако обычно этот процесс обновления кэша работает безупречно.

Быстрое кэширование статичных файлов

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

Заключение

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

Источник: wptavern.com