// codeart.ru / Работаем с кодом / Кэширование в WordPress (1/3) Форум

Кэширование в WordPress (1/3) rss подписка

Автор: Codeart

До сегодняшнего дня я особо не задумывался над тем как в WordPress организовано кэширование данных. Нет, я конечно знал о замечательных плагинах wp-cache и wp-super-cache, но до конца механизм их действия не представлял. Кроме этого я к своему стыду не знал о существовании встроенного WordPress Object Cache. А так же чем встроенный кэш отличается от плагинов. Думаю, что пришла пора разобраться с этим вопросом.

Я планирую написать серию из трех статей на тему WordPress кэширования, в первой статье коротко опишу какие возможности существуют в WordPress для организации так называемого расширенного (advanced) кэширования, а так же объясню в чем разница между кэширующим плагином, и WP-object-cache. Во второй статье более подробно разберу устройства плагина wp-cache, а в третьей затрону вопрос кэширования статических ресурсов, таких как css-файлы, картинки и JavaScript-ы.

Но давайте обо всем по порядку.

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

Первая часть отвечает за проверку наличия данных в кэше и их загрузку. Важно понимать, что если данные в кэше присутствуют, то вторая часть алгоритма не выполняется. Я наиболее часто работаю с кэшированием на уровне шаблонов страниц, когда в кэш попадает либо вся страница полностью, либо какая-то ее часть. При таком способе кэширования, скрипт по загрузке данных располагается в самом начале основной программы. Если страница сохранена в кэше полностью, то возможно оптимизировать загрузку страницы на уровне http протокола (например, используя заголовки expire и etag ). Кроме этого, кэшировать данные можно на уровне объектов или запросов в БД, тогда обе части алгоритма реализуются в месте использования объекта.

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

Разработчики WordPress не стали отходить от описанной выше схемы и предусмотрели возможность кэширования как на уровне объектов (WP Object Cache) так и на уровне страниц (расширенный механизм кэширования).

Для того, чтобы запустить механизм расширенного кэширования, нужно определить константу ‘WP_CACHE’ — «define(‘WP_CACHE’, true);«. Чтобы понять как она влияет на работу WP, давайте посмотрим на код непосредственно относящийся к этой константе:


// For an advanced caching plugin to use, static because you would only want one
if ( defined('WP_CACHE') )
@include ABSPATH . 'wp-content/advanced-cache.php';

Это код располагается почти в самом начале файла wp-settings.php, и выполняется до установки соединения с БД и инициализации основных параметров WP. Когда я первый раз увидел его, ко мне в голову пришла мысль, что файл advanced-cache.php уже существует. Но данное предположение оказалось ошибочным — файл необходимо либо создать самостоятельно, либо установить плагин который сделает это за вас.

Другой кусок кода, относящийся к кэшированию данных так же оказался в wp-settings.php, но уже ближе к концу, и выглядит он примерно так:


if ( defined('WP_CACHE') && function_exists('wp_cache_postload') )
wp_cache_postload();

Функция wp_cache_postload выполняется после того как будут загружены все данные и выполнены все плагины. Это делается потому, что плагины могут изменить содержание загруженной информации. Логичнее всего эту функцию определить в файле advanced_cahce.php. Хотя, опять же, никто не заставляет делать именно так.

Из всего вышесказанного делаем вывод, что первая часть алгоритма кэширования должна быть определена в файле advanced-cache.php, а вторая в функции wp_cache_postload(). Забегая вперед, скажу, что плагин wp-cache так и поступает, у него есть файл wp-cache-pahase1.php, на который создается символическая ссылка с файла advanced_cache.php, а также файл wp-cache-phase2.php, который подключается в функции wp_cache_postload(). Более подробно о том как устроены эти файлы расскажу во второй статье про WordPress кэширование.

Теперь давайте подумаем, зачем нужен расширенный алгоритм кэширования, если в WordPress уже существует Object Cache? Исходя из названия нетрудно предположить, что встроенный в WP механизм кэширования служит для сохранения состояния объектов, а не готовых HTML-страниц. А если быть еще более точным, то данный механизм сохраняет только результаты выполнения SQL запросов.

Чтобы запустить WordPress Object Cache, необходимо определить константу «ENABLE_CACHE» — define(‘ENABLE_CACHE’, true);. После чего в директории wp-content следует создать папку cache, при этом для данной директории важно выставить права на запись пользователю от имени которого работает Веб-сервер. При работе с данным механизмом используются функции: wp_cache_set(), wp_cache_get(). Так как я не планирую более подробно писать об Object Cache, рекомендую ознакомиться со статьей Using the WordPress Object Cache.

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

Leave a Reply

« »