В 14й версии появился встроенный механизм кеширования, но помимо этого, для разработчиков появился механизм "объектного" кеширования. Описание тут
Он заключается в том, что вы сами можете выделить тяжелые участки кода и закешировать их. В этой заметке я поделюсь, как я закешировал главную страницу сайта. Загнал в один объект кеширования 7 циклов. Которые довольно тяжелые. Но в тоже время они не обновляются ежеминутно и для авторизованного пользователя отдавать их вживую - кощунство по отношению к хостингу.
Я имел на главной от 110, до 115 запросов к базе данных. Тут я отступлю и скажу что сам код не проходил рефакторинг и 7 циклов можно было сократить. Но это заняло бы у меня больше времени на оптимизацию чем кеширование.
Итак было 110 запросов в живую и 1,838 секунд на получение первого get страницы.
После кеширования получил такие результаты: запросов 32, время 0,672 секунды.
Что кешировал на главной странице и почему такой выбор? Блок автора у меня выводится в хидере, поэтому, чтобы другим пользователям отдавать его "живым" с актуальными данными пользователя - я не включил его в кэш. Футер у меня не несет ничего кроме html, его я тоже не стал кешировать. Все остальное подверглось кешированию. Т.е. Закешировал всё, кроме пользовательских данных.
Читаем статью и делаем по ней. Этот пример оттуда.
Выводом контента на главную страницу у меня занимается файл index.php
Все то что я хотел кешировать я вынес в отдельный файл include-fo-home.php и подключил его в index.php. Мне это показалось проще - чтобы не дублировать этот код если функция не пройдет проверку.
<?php include (TEMPLATEPATH . '/header.php'); ?> <?php if(function_exists('wp_recall')){ //определяем объект кеширования $rcl_cache = new Rcl_Cache(3600); //проверяем следует ли использовать кеширование if($rcl_cache->is_cache){ //указываем уникальный ключ для кеш-файла $string = 'bff_my_home_page'; //получаем данные кеш-файла по указанному ключу $file = $rcl_cache->get_file($string); //проверяем актуальность кеш-файла if(!$file->need_update){ //возвращаем содержимое кеш-файла echo $rcl_cache->get_cache(); } else { //проверяем используется ли кеш ob_start(); include (TEMPLATEPATH . '/incl/include-fo-home.php'); $twos_contents = ob_get_contents(); ob_end_clean(); if($rcl_cache->is_cache){ //создаем или обновляем кеш-файл с сформированным контентом $rcl_cache->update_cache($twos_contents); } echo $twos_contents; } } } else { include (TEMPLATEPATH . '/incl/include-fo-home.php'); } ?> <?php include (TEMPLATEPATH . '/footer.php'); ?>
Смотря на код сверху вниз:
подключаем хидер
Проверяем, а включен ли у нас плагин wp-recall
Если не включен, то подключаем include-fo-home.php на 34 строке (про это дублирование я и говорил выше)
кеширование на час: new Rcl_Cache(3600)
на 22 строчке включаем буфер ob_start
и подключаем наш файл.
футер не включен в кеширование.
Механизм достаточно простой. 90% кода приведенного здесь - это из статьи по использованию кастомного кеширования.
Заметка показывает частный случай - но общий принцип показанный в ней, вам поможет начать кешировать ваши тяжелые объекты.
Здесь я не написал сброс кэша при публикации записи на сайте. Андрей это сделал ранее в своей статье.
Кэш лежит по пути /wp-content/uploads/rcl-uploads/cache/ и вы экспериментируя, можете через фтп клиент удалять его оттуда.
Спасибо Андрею за терпение и подсказки использования кеширования.
В следующей заметке я вам покажу пример кеширования комментариев, сброса кэша при публикации нового комментария и мой выход из ситуации, когда комментарии разбиваются более чем на одну страницу.
p.s. я не использовал на сайте плагины кеширования. Там ситуация такая, что кэш отдается гостям, а авторизованным пользователям отдается все та же живая версия сайта.
Но есть плагины кеширования которые и этот момент учитывают и отдают авторизованным кэш исключая некоторые динамические объекты. С такими плагинами я не разбирался - мне интересен метод от плагина wp-recall. Зачем ставить еще один плагин? wp-recall справляется, надо лишь правильно подойти к этому вопросу.
Мои результаты с Memcached backend for the WP Object Cache.
Главная:
Было: 20 Mb / 1 сек / 120 запросов
Стало: 16.86 Mb / 0,22653 сек / 16 запросов
+ этот плагин автоматически кеширует многие значения: кастомные поля постов, пользователей и т.п. и при их обновлении - сбрасывает кеш.
Мне кажется кешу от wp-recall надо учиться работать с озу, тогда, лично я, возможно буду использовать его.
Это для авторизованного пользователя?
Да, гостям я отдаю статику
и когда рейтинг реколл начисляют - в панели управления он изменяется сразу - или пока кэш не обновится?
Сразу. Вообще он кеширует все post_meta,get_terms,comment_meta, post_tag_relationships, wp_userlogins, wp_userslugs и т.д. и т.п.
Пока что "проблема" из-за этого только 1на мне встретилась: у меня стоит счетчик просмотров от kama, а он заносит данные о просмотре напрямую в базу, не используя функцию WP, из-за этого в категориях просмотры обновляются только при сбросе кеша. на странице записи норм, там счетчик просмотров берется напрямую из БД и он не кешируется. Но лично для меня это не проблема, ничего страшного в том, что кол-во просмотров у поста на странице категории обновится раз в день - не вижу.
Спасибо за ответ. Интересно.
Но не будем забывать что это только начало пути кеширования в wp-recall. Думаю дальше он будет развиваться. Благодаря таким комментариям как ваш - это поспособствует также.
из описания данной "проблемы" вытекает вопрос: как функционал указанного вами плагина умудряется работать с данными wp-recall, если практически все дополнения используют для хранения своих данных кастомные таблицы и функции?
Андрей Plechev, слишком сложный вопрос, я не совсем его понял :))
Упомянутый мной плагин просто заменяет стандартный кеш объектов wordpress, который по умолчанию хранится только на время генерации страницы. А с эти плагином, все что использует кеш объектов wordpress - автоматически кешируется в ОЗУ. А если, например, идет обновление кастомного поля поста с ID 99 (не напрямую в бд, а через функцию wordpress) то кеш этого кастомного поля для поста 99 сбрасывается.
Ну, а если плагин / функция не использует объектное кеширование wordpress - то данные просто не кешируются в ОЗУ и все
сам задал вопрос и сам дошел до ответа: в том то и дело, что данные плагина wp-recall обновляются сразу, так как кеширование через ОЗУ с ними не работает. Все встало на свои места, спасибо. Будем рассматривать поддержку ОЗУ при дальнейших доработках.
Никто не против, того, что используется кеширование со стороны, приятно, когда у человека руки растут из нужного места и он в состоянии прикрутить и настроить то кеширование, которое его устраивает.
Смысл данного функционала от wp-recall в кешировании своих данных, а кто и как будет его использовать и будет ли вообще личное дело каждого.
В будущем данный функционал будет расширяться и становится гибче, варианты работы с ОЗУ будут также рассматриваться.
Вообще мне нравится как сделаны функции у wp-kama - там он в основные засовывает поддержку wp_object_cache, в результате чего если поставить в функцию cache=true - все данные будут кешироваться в ОЗУ (если конечно стоит плагин объектного кеширования в мемкеш)
К чему я: в идеале, конечно же, хотелось бы что бы при включении кеша wp-recall можно было выбрать: включить файловый кеш или кеш объектов wp. Тогда например у меня все бы кешировалось в ОЗУ и было бы круче, а те у кого мало ОЗУ, нет мемкеша или еще что-то - использовали бы файловое кеширование