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.8:
    • Добавлена украинская локализация (спасибо Андрею К.).
  • Версия 1.2.7:
    • Добавлена белорусская локализация (спасибо Antsar);
    • Добавлена экспериментальная возможность использовать свежие данные в панели администрирования (данные будут браться из базы данных, кэш при записи будет обновляться).
  • Версия 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» (201)  »

  1. Станислав

    Плагин версии 1.2.8, WordPress 2.9.2

    Плагин не сохраняет настройку “Не использовать плагин в админке”.
    В результате плагин не дает редактировать посты блога, конфликтуя с другим плагином (YAPB) и выдавая такое сообщение:

    Catchable fatal error: Object of class YapbImage could not be converted to string in /var/www/waralbum.ru/htdocs/wp-includes/formatting.php on line 427

    • Плагин не сохраняет настройку “Не использовать плагин в админке”.

      Обновитесь.

      и выдавая такое сообщение: Catchable fatal error: Object of class YapbImage could not be converted to string in /var/www/waralbum.ru/htdocs/wp-includes/formatting.php on line 427

      Обратите внимание, что ошибка обнаруживается в wp-includes/formatting.php. Причем указывает на класс YapbImage из YAPB. Причем тут File Cache?

      Если интересно, сделайте backtrace, увидите, откуда растут ноги :-)

      А вообще WordPress 2.9.2, WP File Cache 1.2.8, YABB 1.9.24 — всё отлично работает (только Suhosin ругается)

  2. Станислав

    Обратите внимание, что ошибка обнаруживается в wp-includes/formatting.php. Причем указывает на класс YapbImage из YAPB. Причем тут File Cache?

    Если FileCache активен, то ошибка появляется. Если не активен – ошибки нет. Это значит, что именно FileCache вызывает ошибку. Хотя сообщение об ошибке не говорит об этом буквально.

    Обновитесь.

    Обновил и Вордпресс, и YapBB. Всё то же самое – настройка “Не кэшировать в админке” не запоминается, указанная выше ошибка – на месте.

    • Всё то же самое – настройка “Не кэшировать в админке” не запоминается

      WordPress-то зачем обновлять? WP File Cache обновите.

      Это значит, что именно FileCache вызывает ошибку.

      К слову, совсем не значит ;-) Будет не лень, посмотрите на YapbBaseOption::update_html_option(). Реализация метода не до конца совместима с WordPress Options API.

      Не поленитесь, сделайте backtrace в wp_check_invalid_utf8().

    • Вам в любом случае отключение кэша в админке не поможет — плагин изменяет объект с постом перед тем, как тот попадает в кэш (случается не всегда). В объект добавляется еще один объект (типа YapbImage), на котором функция sanitize_post() и обламывается (так как ожидает строку). Лечить нужно именно плагин.

    • Если вообще конкретно — то ошибка в фильтре Yapb::_filter_the_posts(). Он вызывается по событию the_posts — после того, как список постов был получен из базы, но перед тем, как он попадёт в кэш. Плагин делает так:

      [-]
      View Code PHP
          $post = &$posts[$i];
          if (!is_null($image = YapbImage::getInstanceFromDb($post->ID))) {
              $post->image = $image;
          }

      $post->image = $image; — так делать нельзя, так как WordPress не ожидает объектов внутри данных поста.

      Это значит, что именно FileCache вызывает ошибку.

      Это значит, что автор YAPB плохо знает внутренности WordPress.

    • Станислав, рецепт исправления плагина здесь.

  3. тёма

    СКажите пожалуйста а сколько он хранит кеш для пользовательских груп или же он его постоянно создаёт?

  4. Заметил одну особенность этого полезного плагина. Он не кэширует запросы которые сделаны “своими руками”. То есть если я, например, в файле functions.php (тот который лежит в файлах темы) использую SQL запрос к базе через стандартный $wpdb->query. Запросы самого движка WP кэшируются.
    Так и должно быть или это бага?
    Запросы наблюдаю через $wpdb->queries.
    WP 2.7 + FC 1.2.1 – не пинать, пока обновить не могу. :-)

    • Так и должно быть. Если Вы хотите закэшировать запрос, нужно использовать WordPress Cache API.

      Как-то так:

      [-]
      View Code PHP
      $data = wp_cache_get('key', 'group');
      if (!$data) {
          $data = $wpdb->get_results("...");
          wp_cache_set('key', $data, 'group', $ttl); //$ttl - время жизни объекта в кэше
      }

      // Можно использовать $data
  5. Зависит от WordPress и конкретных плагинов. Максимальное время жизни составляет один час.

  6. Здравствуйте Владимир!
    Спасибо за блог и плагины!

    Не могли бы Вы коротко объяснить, как работает стандартный кеш WP? Меня интересует, то куда он сохраняется, отдельно в файлы или куда-то в буфер? Т.е. ваш плагин создает поддержку межсессионного кеширования и кеш сохраняется в определенную папку в файлы, а стандартный кеш WP, где хранится?

    • Wandering Soul

      Меня интересует, то куда он сохраняется, отдельно в файлы или куда-то в буфер?

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

  7. На WordPress 3.0 не работает, не пускает на страницу настройки плагина(говорит что у вас нет полномочий), а после входа в свой профиль, плагин отключается совсем

    • Всё прекрасно работает! Перед обновлением желательно отключать все плагины, тем более кэширующие.
      В вашем случае, если уже произвели обновление и вас не пускает в админку – просто удалите папку wp-file-cache из /wp-content/plugins/ и файл object-cache.php из /wp-content/, после чего установите WP File Cache заново.

    • Wandering Soul

      File Cache принципиально не будет работать с WP 3.0 — слишком много что изменилось в коде. В качестве альтернативы можно использовать Object Cache (в нем есть движок, эмулирующий File Cache).

      • В самом деле?
        Первые 2 скрина с включённым WP File Cache: 01 и 02.
        Вторые два с выключенным: 03 и 04.
        Версия WP: 3.0.1
        Версия WP File Cache: 1.2.8.2
        К тому же стоило внимательно почитать новости по этому плагину:

        Версия 1.2.2:
        Добавлена базовая совместимость с WordPress 3.0.

        • Wandering Soul

          :-) Алексей, Вы не поверите. Совместимость есть, но только базовая, а именно: в object_cache.php переменная $__sjfc_options стала глобальной, так как object_cache.php может вызываться из функции, а не из глобального контекста. А поддержки wp_cache_reset(), возможности повторного вызова wp_cache_init() и прочих вещей, нужных для работы с WPMU/WordPress MultiSite в плагине не было и уже не будет.

          Да, в частном случае может работать, но в конфигурации MultiSite это закончится потерей данных. Поэтому если нужна полноценная поддержка WP 3.0, используйте SJ Object Cache.

          • В режиме MultiSite действительно не пробовал.
            А SJ Object Cache даёт меньший эффект производительности, поэтому и остался на WP File Cache.

          • Wandering Soul

            Алексей, а если не секрет, как производительность измеряли? Я считал, что движок File Cache один и тот же и там, и там.

  8. [...] Спасибо разработчику, Владимиру Колесникову! На его блоге можете найти подробнейшее описание плагина, как его [...]

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

Вы должны быть авторизованы, чтобы иметь возможность оставить комментарий.

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