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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Download

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

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

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

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

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

2
Дек
2008

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

  1. Алексей says:

    А как корректно деактивировать плагин, не навредив содержимому БД?

    • Vladimir says:

      Алексей, WP FileCache базу данных не трогает.

      Отключите плагин и удалите файл (если он не будет удален автоматически) /wp-content/object-cache.php.

  2. Роланд Чанишвили says:

    У тебя ( как впрочем и в старом кеше WP ) не реализованно время жизни кеша. Нет планов по доработке?

    • Vladimir says:

      Почему? Реализовано. Просто WordPress его нигде не использует. Поэтому верхний предел устаревания данных составляет один час.

  3. Search Bot says:

    Одновременное использование вашего плагина и super cache имеет смысл? Или нужно оставить только file cache ?

    • Vladimir says:

      Имеет. Хотя смотря что Вы добиваетесь.

      • Search Bot says:

        Добиваюсь максимального снижения нагрузки на процессор хостера

        • Vladimir says:

          Боюсь, что в этом случае WordPress — не самая подходящая платформа для Вашего сервера.

          • Search Bot says:

            Ваш ответ выдает в вас программиста

          • Vladimir says:

            А я и есть программист. И один из разработчиков WordPress. И как человек, которому приходится изо дня в день копаться в коде WordPress, я отлично вижу его сильные и слабые стороны. И если хостер жалуется на то, что Ваш сайт потребляет слишком много процессорного времени, то Вам нужно либо использовать вместо WordPress что-то другое, либо использовать костыли, которыми и являются кэширующие плагины. Но если Вы хоститесь на виртуальном сервере, то кэширующие плагины при большой нагрузке только испортят производительность, потому что виртуалки хуже справляются с интенсивным вводом/выводом (как результат, процессор будет тратить много времени в iowait).

            Если Вы посмотрите на статистику IOstat (взята с выделенного сервера, сайт на котором входит в Alexa Top 100,000, работает на WordPress и используюет WP SuperCache):

            то заметите, что основная нагрузка — это запись на диск (а не чтение), что делает кэширование файлов бесполезным. А виртуализаторы с IO, к сожалению, хреново работают.

            Так что делайте выводы.

            PS — для сравнения: IOstat с сервера, не использующего костыли:

            Почувствуйте разницу :-)

          • Search Bot says:

            Спасибо за развернутый ответ! На моём виртуальном хостинге после включения кеширующих плагинов WP нагрузка на CPU выросла. Сейчас отрубил все плагины, посмотрим, какая разница.

  4. Search Bot says:

    И ещё вопрос: как настроить время жизни кеша в плагине?

    • Vladimir says:

      Время жизни задаётся разработчиками, когда они используют вызов wp_cache_set(). Если время не задано, TTL устанавливается в один час.

      • Search Bot says:

        А как сделать 24 часа?

        • Vladimir says:

          Используйте Super/HyperCache, у данного плагина цель другая. Соль в том, что разработчик определяет время жизни данных в кэше, чтобы все данные оставались согласованными. Если тупо поставить срок жизни в 24 часа, результат будет, хм, плачевным.

  5. [...] WP FileCache: долговременное кэширование в WordPress [...]

  6. Dimox says:

    Владимир, подскажи, плиз, что нужно указать в поле “Несохраняемые группы”, чтобы не кэшировалось облако тегов?

    • Vladimir says:

      Что-то мне подсказывает, что terms. Попутно это отключит кэширование всех таксономий.

      А что с облаком тэгов не так?

      • Dimox says:

        После публикации постов облако не обновляется до тех пор, пока не сброшу кэш.

  7. pixel says:

    привет, подскажи пожалуйста когда стоит ставить плагин, когда проект вырастет или сразу же.

    цель: снизить нагрузку

    лучше ставить wp file cash?

    какие минусы, проблемы есть при включении кэширования (взять к примеру тотже wp file cash)

    —-
    просто интересно (wordpress создает нагрузку неплохую, ты говоришь что это не лучший вариант, а что лучше ставить в таком случае, самописную цмс?)

    • Vladimir says:

      цель: снизить нагрузку

      Если хостинг виртуальный, то лучше вообще не ставить. Посмотри «WP SuperCache и высокая нагрузка: часть 2». Там видно, что при включенном плагине кэширования возрастает количество записей на диск. Виртуалки, как я уже много раз говорил, хреново обрабатывают I/O. Нагрузку-то ты снизишь, но сайт будет подтормаживать из-за повышенного iowait.

      а что лучше ставить в таком случае, самописную цмс?

      Если хорошо пишешь, то да.

  8. pixel says:

    Спасибо :)

  9. Stepan says:

    Владимир, здравствуйте!
    Я вам писал на почту по поводу доработки плагина, очень надеюсь получить ответ.
    Нужно увеличить срок жизни кеша, сервера не справляются:( Сайты статичные - на них ничего не обновляется, комментов и т.д. нету. Поэтому нужен т.н. “вечный кеш” с возможностью сброса через админку.

    • Vladimir says:

      Буду дома — проверю. А почему Вы не хотите использовать WP SuperCache или HyperCache? Они для этого подходят больше, чем FileCache.

      • Stepan says:

        Потому что они кешируют страницы целиком в html - начинаются проблемы с исполнением дополнительных php скриптов на страницах и т.д.

        • Vladimir says:

          Попробуйте поставить SQLMon и посмотреть на запросы. Это ненормально, если «статические страницы» так убивают сервер. Скорее всего, проблема в каком-то плагине. В этом случае, если плагин не использует кэширование WordPress, FileCache помочь не сможет.

          И в любом случае, нужно лечить болезнь, а не её симптомы :-)

Подписаться на RSS-ленту комментариев к статье «WP FileCache: долговременное кэширование в WordPress» Trackback URL: http://blog.sjinks.org.ua/wordpress-plugins/wp-file-cache/trackback/

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

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

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

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