Если не вдаваться в долгие разъяснения, о системе кеширования в WordPress, а попытаться объяснить просто и кратко, то своё пояснение я начал бы с того, что есть некий механизм, который способен снять нагрузку с сервера (место где работает сайт) и тем самым ускорить ваш веб-сайт под управлением WordPress.
Механизм этот называется — кеширование. Принцип работы достаточно простой. Кеширование позволяет использовать готовые сформированные данные, а не генерировать их при каждом повторном обращении к страницам сайта.
Кэш страниц (Page cache)
Чтобы понять суть этого вида кэширования, давайте рассмотрим простой пример. Возьмём этот сайт. Предположим Вася попадает на эту страницу. На сервере (на back-end) происходит много скрытых, невидимых глазу посетителя процессов: обработка запроса, формирования заголовков ответа, выборка данных из базы данных, выполнение логики и вычислительных операций PHP и прочее. В итоге формируется страница, которая должна вернуться в браузер Васи в виде HTML для отрисовки. Сервер получил нагрузку выполняя эту подготовку. Через минуту эту же страницу посещает Петя. Что происходит? Снова происходят те же самые процессы: выборка и обработка данных для формирования страницы, чтобы отправить Пете в браузер. А через пару минут эту страницу посещает девочка Катя. Ну вы догадались что произойдёт, да? 🙂
А представьте, что одновременно эту страницу будут посещать в течении нескольких минут ещё пользователей 100-200 и это нормальная ситуация, даже для свежеиспечённых сайтов. Такую нагрузку может вызвать реклама или рассылка, которая приведёт на эту страницу большое количество посетителей.
Мы можем снять нагрузку с сервера путём страничного кеширования. Проиграем снова эту ситуацию, но уже с реализацией страничного кеширования.
Включен полный страничный кэш
На эту страницу заходит Петя. Происходит та же самая магия: подготовка и обработка данных. Страница сформирована и готова байтами лететь в браузер Пети. Сервер, как обычно отправляет страницу, но за одним исключением. Мы сохраняем копию этой сформированной страницы — это и есть кэш.
Далее заходить на эту страницу сайта Вася. Догадались что будет происходить? Да! Сервер отдаст готовый вариант этой страницы и не будет заново её формировать.
Теперь на время жизни этого кэша всем посетителям сайта будет отдаваться сформированный результат и как следствие — это выигрыш в скорости работы сайта, повышение его производительности за счёт короткого отклика (так как страница уже сформирована) и снятие вычислительной нагрузки.
WordPress не наделён этим механизмом «из коробки» (то есть после установки и первого запуска). Реализовать такое кеширование помогут плагины, такие как:
- WP Super Cache
- W3 Total Cache
- WP Rocket (платный)
Объектный кэш в WordPress
Но в этой статье мы будем говорить об объектном кэшировании в WordPress, которое, кстати, так же «из коробки» является непостоянным. Проиграем опять ситуацию. Заходит на страницу сайта Петя, происходит формирование страницы. И объектный кэш это другой уровень кеширования. На уровне страниц пример был рассмотрен выше и если вы были внимательны, то вспомните что при формировании страницы данные берутся из Базы Данных, то есть происходит, если выражаться техническим языком, их SQL запрос. Представим что запрос был сложный и данные запрашивались из БД по разным критериям (параметрам).
Да, в WordPress есть механизм объектного кэширования в рамках сеанса запрошенной страницы. Предположим, функция get_option() вызывается в рамках страницы 10 раз. Если провести аналогию с кэшированием страниц, то после первого вызова она попадёт в объектный кэш и последующие её вызовы будут уже обслуживаться из встроенного объектного кэша WordPress. Вроде всё классно, неправда-ли? Но что произойдёт если на эту страницу зайдет Вася? Функция get_option() снова будет запрашивать данные и в пока Вася находится на странице и не переходит на другие всё будет хорошо и последующие её вызовы будут обслуживаться из кэша.
Вот это и есть непостоянный объектный кэш. Но нам хотелось бы и это уже само напрашивается, чтобы для новых посетителей сайта не происходили одинаковые запросы из БД, а при повторном запросе данные были взяты из памяти, а не заново формировались ( как по аналогии со страницами).
И это реализуемо. Этот механизм называется — постоянный объектный кэш. Единственное, что реализуется он преимущественно за счёт внешних источников хранения, то есть нужно устанавливать на сервер дополнительное программное обеспечение. И сейчас мы рассмотрим один из самых простых примеров реализации постоянного объектного кэша где как раз таки не нужно ничего устанавливать, хотя есть небольшой нюанс.
Может напрашиваться вопрос: можно ли использовать оба кеширования вместе? Да, можно. И даже если ваш сайт постранично жёстко закеширован, всё равно нужно использовать объектный кэш, что бы уменьшить нагрузку с базы данных при работе, например, в админке, при работе в режиме авторизации пользователей, на страницах которые не должны кэшироваться, такие как корзина и страница оформления заказа и наверняка можно найти целый ряд дополнительных случаев оправдывающих постоянный объектный кэш даже в связке с грамотным страничным.
Кейс (реальный случай)
Мы решили организовать на своём сайте постоянный объектный кеш. Виртуальный хостинг не имеет в своём ПО сервис Redis, а следовательно после активации плагина мы не сможем его задействовать, так как наш тарифный план не включает установку дополнительного программного обеспечения.
Как же быть в этом случае?
Плагин Docket Cache
Страница для скачивания плагина.
Docket Кэш — это плагин для реализации постоянного кеша объектов в WordPress, который хранится в виде PHP-кода. Задача плагина предоставить альтернативный вариант для постоянного объектного кэша для тех, кто не может использовать на своих серверах такие сторонние решения, как: Redis или Memcached.
После активации плагина нам становятся доступны его разделы настроек:
Принцип работы плагина отличается от популярных решений, таких как Redis или Memcached, а также Docket Cache не использует механизм сериализации/десериализации объектов PHP для хранения в файлах в виде строк, а сохраняет данные путем преобразования объекта в простой PHP-код, что приводит к более быстрому извлечению данных и повышению производительности при включенном Zend OPcache.
Что такое Zend OPcache?
OPcache — это механизм кэширования, встроенный в PHP, который повышает производительность за счет хранения предварительно скомпилированного байт-кода сценария в общей памяти, тем самым устраняя необходимость PHP загружать и анализировать сценарии при каждом запросе.
Docket Cache преобразует кэш объектов в простой PHP-код. При чтении и записи кеша он будет напрямую использовать OPcache, что приводит к более быстрому извлечению данных и повышению производительности.
У плагина много всяких настроек доступных в разделе Configuration, включите некоторые из них:
В разделе Обзор можно увидеть статистику кеширования — это хороший знак, значит плагин работает 🙂
Есть также отдельный раздел OPcache где мы можем получить техническую информацию, в частности полезно понимать сколько доступно и задействуется памяти для хранения. Ну и сами файлы с кэшем.
Требования
Для использования Docket Cache нужно выполнить минимальные требования:
- PHP 7.2.5
- WordPress 5.4
- Zend OPcache
Естественно все тонкости и настройки рассматривать смысла я не вижу. Главное что бы ваш сервер и его ПО удовлетворял минимальным требованиям и после активации плагина появлялись файлы, статистика кэша. Для начала это уже будет неплохо 🙂
Вот так хранится кэш на сервере. Это директория для хранения.
А вот файлы и их содержимое
Хранятся данные в виде массивов в синтаксисе PHP
Для технических специалистов возможно будет полезна эта ссылка на документация плагина
Подытожим об объектном кешировании
Кэширование объектов — это процесс, который сохраняет результаты запросов к базе данных, чтобы быстро восстановить их в следующий раз, когда они потребуются.
Кэшированный объект будет оперативно обслуживаться из кеша, а не отправлять несколько запросов в базу данных. Это более эффективно и снижает огромную ненужную нагрузку на ваш сервер.
Проще говоря, кэширование объектов позволяет копировать часто используемые объекты и хранить их в более близком месте для более быстрого использования.
