WP File Cache: долговременное кэширование в WordPress

Повышение производительности WordPress в один клик

Как известно, поддерживает два вида кэширования:

  1. Кэширование на уровне страниц;
  2. Кэширование на уровне запросов.

Кэширование на уровне страниц поддерживает, но самостоятельно не реализует, вследствие чего приходится использовать сторонние плагины (Hyper Cache, WP Super Cache и т.д.). При всех достоинствах постраничного кэширования, у него есть несколько недостатков, а именно:

  • невозможность использования динамических элементов (например, captcha, работающая по методу «изящного отсеивания спама») или виджетов, генерирующих динамический контент (например, quote of the day);
  • плагины, которые отдают комментатору статическую версию страницы (в этом был замечен Hyper Cache), вынуждают пользователя каждый раз вводить свои данные (имя, сайт, email) заново.

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

Очевидно, что если сохранять между сессиями (что поддерживает, но самостоятельно реализовать не может), это может весьма положительно повлиять на .

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

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

Первая версия плагина родилась у меня давно — еще в июне. И лишь недавно я нашел время, чтобы привести в человеческий вид, добавить интерфейс для администратора и перевести на русский язык.

Функциональность плагина:

  • реализация долговременного кэширования на уровне запросов;
  • полная совместимость с интерфейсом класса WP_Object_Cache ;
  • использование памяти под сессионный для увеличения производительности;
  • сессионное кэширование часто изменяющихся объектов;
  • хранение настроек в коде плагина.

Особенности плагина:

  • возможность отключения кэширования (в том числе и встроенного в );
  • возможность отключения межсессионного кэширования;
  • возможность задания групп, не подлежащих межсессионному кэшированию (полезно только разработчикам, которые знают, о чём идёт речь);
  • хранит свои настройки непосредственно в коде (в файле wp-content/object-cache.php). Это связано с проблемой курицы и яйца, а также с архитектурными особенностями : дело в том, что инициализирует вызовом wp_cache_init(): при обработке данного вызова должен инициализировать . Если бы настройки хранились в таблице wp_options, бы использовал функцию get_option(). Но функция get_option() вызывает wp_cache_get(), а wp_cache_get() не может использовать , потому что он не инициализирован. В принципе, это не является проблемой; проблема заключается в том, что get_option() читает все опции из таблицы, для которых autoload установлен в 1. На практике это 90–95% таблицы. Ранее я уже писал, что в целом и get_option() в частности спроектированы так, что если кэширующий модуль не вернул данные, функция затребует их вновь и в полном объеме. Иными словами, опции будут загружены дважды (два обращения к базе данных). А это нехорошо. Поэтому настройки хранятся непосредственно в коде.

существует в двух локализациях: русской и английской. Если есть желание перевести на другой язык, пишите.

Замечания по установке:

После активации для хранения кэша будет использовать каталог wp-content/plugins/file-cache/cache. Поэтому перед активацией каталог должен быть доступен на запись. Каталог для хранения кэша можно изменить в настройках (для увеличения производительности имеет смысл размещать на RAM-диске); каталог также должен быть доступен на запись.

Плагину при активации/сохранении настроек должен быть доступен на запись каталог wp-content: в него копируется файл object-cache.php. После того, как активирован и сконфигурирован, права на запись можно убрать.

Удаление/деактивация плагина:
Для успешной деактивации каталог wp-content должен быть доступен на запись — требуется удаление файла wp-content/object-cache.php.

Для срочной деактивации плагина можно удалить или переименовать файл wp-content/object-cache.php. В этом случае будет использовать встроенные механизмы кэширования.

Download

Скачать последнюю версию плагина WP File Cache.

Список изменений

  • Версия 1.2.5:
    • Кэшируемые данные больше не передаются по ссылке, что позволяет избежать случайного изменения данных в кэше;
    • Кэшируемые объекты перед помещением в клонируются (из тех же соображений).
  • Версии 1.2.3–1.2.4:
    • Размещение плагина в репозитории и исправление ошибок, вызванных изменением каталога плагина. Спасибо Raveex за терпение и тестирование.
  • Версия 1.2.2:
    • Добавлена базовая совместимость с  3.0.
  • Версия 1.2.1:
    • Оптимизация кода, ускорение работы кэширующего движка;
    • Блокировка файла при записи;
    • Использование меньшего количества системных вызовов при записи файлов.
  • Версия 1.1
  • Версия 1.0
  • Версии 0.2.x

Оценки производительности

  1. «Голый» WordPress 2.7rc1:
    1. Кэширование запрещено: 191 запроса, 0.587 с
    2. Встроенный в : 18 запросов, 0.350 с
    3. : сессионное кэширование: 18 запросов, 0.334 с
    4. : долговременное кэширование: 3 запроса, 0.315 с
  2. Данный сайт:
    1. Кэширование запрещено: 1442 запроса, 3.558 с
    2. Встроенный в : 51 запрос, 0.776 с
    3. : сессионное кэширование: 51 запрос, 0.615 с
    4. : долговременное кэширование: 13 запросов, 0.576 с

Добавить в закладки

Связанные записи

Автор: Vladimir; метки: WordPress, WP File Cache, кэш, плагин, производительность

RSS Комментарии к статье «WP File Cache: долговременное кэширование в WordPress» (165)  »

  1. Почините ваш плагин пожалуйста!!!

    Установила, выкинуло ошибку:

    Warning: require_once(/home/bc/sites/olyapka.ru/www/wp-content/plugins/file-cache/lib/class.FileCache.php) [function.require-once]: failed to open stream: No such file or directory in /home/bc/sites/olyapka.ru/www/wp-content/object-cache.php on line 4

    Переименовала вашу папку wp-file-cache в /file-cache – заработал. Но не открываются опции, выдает “нет такого файла”. Вам об этом кстати выше говорили – http://blog.sjinks.pro/wordpress-plugins/wp-file-cache/comment-page-5/#comment-2917

  2. kama

    А этот плагин будет корректно работать, если установлено 2 сайта на один движок?
    Т.е. двиг один и БД тоже одна, но там разные префиксы у таблиц, т.е. как бы получается 2 разные базы данных в одной и управляются они одним движком (папкой). Оба сайта на одном шаблоне работают, в зависимости от используемой БД в шаблоне меняются некоторые элементы. Ну и админка соответственно разные данные выводит и настройки ВП тоже разные (они ж в бд хранятся.)

    • Вряд ли. Так как если используется одна установка WordPress, то и кэш будет один — глобальный.

      Единственное решение — изменить в файле object-cache.php в функции wp_cache_init() механизм определения пути к кэшу в строке

      [-]
      View Code PHP
      $path = ('' == trim($options['path'])) ? (dirname(__FILE__) . '/plugins/wp-file-cache/cache') : trim($options['path']);

      Путь для каждого сайта должен быть своим.

      Но скажу честно, я такую конфигурацию не тестировал.

      • Работает, при условии, что для каждой базы со своим префиксом используется своя папка, т.е. если база с префиксом, например, wp1_ и сам WP находится в имя_папки_1 и в той же базе есть база с префиксом wp2_ и сам WP находится в имя_папки_2.

      • Забыл сказать, что вышеописанное мной работает без хирургического вмешательства в сам плагин.

  3. kama

    Папку удалить не могу с вашим плагином wp-content/wp-file-cache/cache папка сама появляется. через фтп и через админ панель хостера удалял нифига wp-content/wp-file-cache/en-cache папка с кешом внутри появляется сама по себе сразу после удаления. Что может быть? Где настройки Вашего плагина хранятся?

    • Настройки хранятся непосредственно в wp-content/object-cache.php. Строка вида

      [-]
      View Code PHP
      $GLOBALS['__sjfc_options'] = 'a:4:{s:7:"enabled";i:1;s:7:"persist";i:1;s:4:"path";s:0:"";s:13:"nonpersistent";s:0:"";}';
      • Евгений

        Так как все таки удалить эту папку? Я этот файл снес вообще…а папка не удаляется? Что делать?

        • Перед тем, как сносить, нужно было очистить кэш. Плагин бы сам всё почистил.

          В Вашем случае у файлов кэша, вероятно, другой владелец.

          Залейте по FTP этот PHP-файл и выполните его:

          [-]
          <?php
          function remove_dir($dir, $self)
          {
              $dh = @opendir($dir);
              if (false === $dh) {
                  return;
              }

              while (false !== ($obj = readdir($dh))) {
                  if ('.' == $obj || '..' == $obj) {
                      continue;
                  }

                  if (false == @unlink($dir . '/' . $obj)) {
                      remove_dir($dir . '/' . $obj, true);
                  }
              }

              closedir($dh);
              if ($self) {
                  @rmdir($dir);
              }
          }

          remove_dir('путь к кэшу', true);
          ?>
  4. [...] У создателя моего любимого файлового кеша под WP, вышел плагин быстрого объектного кеша, рекомендуется [...]

Оставить комментарий к записи «WP File Cache: долговременное кэширование в WordPress»

Вы можете использовать данные тэги: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Изображения должны быть включены!

Оставляя комментарий, вы выражаете своё согласие с Правилами комментирования.

Подписаться, не комментируя