Ars Longa, Vita Brevis

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

Как известно, 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 с

[is_not_feed][/is_not_feed]

Добавить в закладки
  • del.ici.ous
  • Digg
  • Furl
  • Google
  • Simpy
  • Spurl
  • Y! MyWeb
  • БобрДобр
  • Мистер Вонг
  • Яндекс.Закладки
  • Текст 2.0
  • News2
  • AddScoop
  • RuSpace
  • RUmarkz
  • Memori
  • Закладки Google
  • Писали
  • СМИ 2
  • Моё Место
  • Сто Закладок
  • Ваау!
  • Technorati
  • RuCity
  • LinkStore
  • NewsLand
  • Lopas
  • Закладки - I.UA
  • Connotea
  • Bibsonomy
  • Trucking Bookmarks
  • Communizm
  • UCA

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

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

  1. [Декабрь 2, 2008 14:25] AlexNote:

    Чем лучше/хуже гиперкеша или ВП-суперкеш?

    Ответить на данный комментарий

    #1
    • [Декабрь 2, 2008 14:56] Vladimir:

      Alex, разные принципы работы.

      WP SuperCache, равно как и HyperCache, относятся к кэширующим плагинам первого типа (постраничное кэширование). Они перехватывают вывод страницы после работы всех плагинов и записывают её в кэш. При следующем обращении к странице они отдают статическую версию страницы. Это и хорошо, и плохо.

      Преимущества понятны: высокая скорость, минимум обращений к БД. Недостатки — проблемы с динамическим контентом, генерируемом на стороне сервера. То есть если сервер при каждом обращении к странице пишет в нее “Данная страница была запрошена X раз”, при использовании Super/HyperCache вся эта динамика идёт лесом. Другой недостаток — такие плагины бьют cookies. Страница в кэше должна быть имперсонифицирована (из-за privacy), поэтому комментатору придётся вводить свои данные каждый раз.

      WP File Cache построен по другому принципу: он кэширует не страницы, а результаты запросов. Производительность будет упираться в сторонние плагины, так как не все плагинописатели знают, как использовать API WP_Cache_Object.

      Преимущества этого подхода заключаются в решении недостатков первого способа, а недостатки — в невозможности использования в полной мере преимуществ первого способа :-)

      Из плюсов: WP File Cache можно использовать совместно с Super/HyperCache. Конфликтовать не будут. Но останутся недостатки первого подхода.

      Ответить на данный комментарий

      #2
  2. [Декабрь 2, 2008 18:56] Roland Chanishvily:

    Отличный плаг, спасибо!
    Прорекламировал у себя в блоге.

    Ответить на данный комментарий

    #5
  3. [Декабрь 3, 2008 23:21] Dimox:

    Владимир, спасибо за плагин! Поставил у себя. На главной количество запросов уменьшилось с 48 до 18. На странице с ~200 комментариями уменьшилось с 70 до 48. Весьма неплохой результат.

    Ответить на данный комментарий

    #7
  4. [Декабрь 5, 2008 04:07] oldvovk:

    В чем проблема на 263
    Фатальная ошибка активации
    Parse error: parse error, unexpected T_STRING, expecting T_OLD_FUNCTION or T_FUNCTION or T_VAR or ‘}’ in z:\home\wp26.tut\www\wp-content\plugins\file-cache\file-cache.php on line 13

    Ответить на данный комментарий

    #13
  5. [Декабрь 6, 2008 01:03] Алексей:

    Владимир, спасибо Вам за то что делитесь такой полезной и необходимой информацией!
    У меня есть нескромный вопрос/просьба - не поделитесь ли Вы своей супер скоростной сборкой Вордпресс?
    Думаю многие были бы Вам очень признательны, не только я :-)

    P.S. не знаю может Вы уже и выложили но я плохо искал …

    Ответить на данный комментарий

    #17
  6. [Декабрь 6, 2008 20:31] Недокументированные особенности APC | Ars Longa, Vita Brevis:

    [...] APC с позиции его возможного применения в плагине WP File Cache, но при реализации модуля столкнулся с некоторыми [...]

    Ответить на данный комментарий

    #20
  7. [Декабрь 7, 2008 11:51] Lecactus:

    поставил потестить. с плагином включенным число запросов падает примерно в 2 раза, время генерации и потребление памяти неизменное 0.2-0.3сек.
    реально же страница стала открываться примерно на секунду ДОЛЬШЕ (подозреваю что из-за кучи мелких файлов кэща)

    ради интереса отключил галочку Включить FileCache и посмотрел на морду сайта

    АХТУНГ: MySQL: 1754запросов / 6.322 секунд!!!!!!!!!!!! (короче говоря то что было в недавнем посте про “под микроскопом” http://blog.sjinks.org.ua/wordpress/410-monstrosa-horribilis/) + испоганилась галерея на странице.

    и как теперь верить тому посту что авторы сделали встроенный кэш только ради производительности? с этом “встроенным кэшем” такого мегабага нету и таких тормозов тоже (да их вообще нету в принципе)

    corrupted-gallery.png

    Ответить на данный комментарий

    #21
    • [Декабрь 7, 2008 18:36] Vladimir:

      потребление памяти неизменное

      Оно как бы и не должно меняться

      время генерации неизменное

      реально же страница стала открываться примерно на секунду ДОЛЬШЕ

      Вот это я не понял: если время генерации одинаковое, как страница открывается дольше? Клиент получает одинаковое число файлов.

      подозреваю что из-за кучи мелких файлов кэща

      Они клиенту не отдаются. Кстати, а на какой файловой системе проходил тест?

      испоганилась галерея на странице

      Галерея — это уже интересно. Какой там плагин, если не секрет?

      ради интереса отключил галочку Включить FileCache и посмотрел на морду сайта

      Отключение FileCache отключает всякое кэширование, в том числе и WordPress’овское (так он устроен: если подключается сторонний кэш, свой родной не подключается).

      и как теперь верить тому посту что авторы сделали встроенный кэш только ради производительности?

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

      Поэтому встроенный кэш — это костыль.

      Я сейчас смотрю в сторону APC и memcached, но всё же файловый кэш доступнее для большинства пользователей.

      с этом “встроенным кэшем” такого мегабага нету и таких тормозов тоже (да их вообще нету в принципе)

      Я бы с этим согласился, если бы лично не видел обратного. При большой нагрузке load average возрастает до космических пределов. Если хостинг совместный, аккаунт блокируется, если хостинг выделенный, система умирает.

      Ответить на данный комментарий

      #22
      • [Декабрь 8, 2008 08:25] Lecactus:

        клиент получает да, то же число файлов.
        а почему оно не должно изменяться? (время генерации) если запросолв по сути в 2 раза меньше? или оно считается уже на выходе и не важно из кэша берется или напрямую?
        файловая система ext3
        галерея стандартная, но выводится через плагин shutter reloaded и генерируется не просто из миниатюр, а из миниатюр с подписями картинок
        на сервере используется php-акселератор eaccelerator + нгинкс на фронте
        нагрузка выростала у меня когда то до космических размеров на старом сервере без использования суперкэша. любое файловое кэширование запросов , которые было во времена вп2.2 и 2.3 не давало по сути никакого прироста. нажатие Ф5 на любой странице в браузере в течение минуты давало дикую нагрузку.
        правда тогда я не использовал ни акселератор, ни нгинкс

        также при включенном плагине этом заметил такое - на странице архива у меня выдает
        MySQL: 243запросов / 1.199
        а без плагина
        MySQL: 34запросов / 1.576
        плагин архива такой http://www.viper007bond.com/wordpress-plugins/clean-archives-reloaded/

        а вообще в целом при использовании плагина не заметил ни ускорения работы, ни уменьшение ни увеличение потребления процессорного времени.

        PS не поделитесь фичей загрузки аттачей в коменты? плагин или самописное?

        Ответить на данный комментарий

        #23
        • [Декабрь 8, 2008 20:12] Lecactus:

          потестил тот пропатченный functions.php - с ним показывает
          926запросов / 0.858 на главной вместо выше названных примерных 1754запросов / 6.322

          прогнал еще несколько раз архив перезагрузкой страницы - упало до 15запросов/0.9сек с плагином. патченный или нет functions.php - разницы нет

          еще баг/фича плагина - после деактивации он не удаляет за собой object-cache.php и кэш продолжает использоваться…

          Ответить на данный комментарий

          #24
          • [Декабрь 9, 2008 12:33] Vladimir:

            патченный или нет functions.php - разницы нет

            С кэшем разницы и не будет — я переписал get/update/add_option с учетом масштабируемости: отказался от идеи каждый раз лезть в кэш за опциями.

            Результат — количество запросов на главной упало почти вдвое, время генерации уменьшилось почти в 8 раз. Со встроенным кэшем изменения, навреное, не будут особо заметны (тем более, если стоит акселератор).

            Мне просто было интересно протестировать переписанный functions.php — хочу предложить код разработчикам, так как он лучше масштабируется.

            #25
          • [Декабрь 9, 2008 12:35] Vladimir:

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

            А права на wp-content позволили ему удалить object-cache.php? Он при деактивации ругаться не умеет

            #26
        • [Декабрь 9, 2008 13:58] Vladimir:

          а почему оно не должно изменяться?

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

          Время же генерации будет меняться (Вы написали, что оно неизменное, но страница открывается дольше — я и удивился: время генерации считается с момента выполнения wp-settings.php и до конца выполнения кода WordPress, пожтому при одинаковом времени генерации время загрузки тоже должно быть примерно одинаковым).

          файловая система ext3

          Эх… Для такого кэша reiser или tmpfs самое то. Я делал в tmpfs (типа ramdrive) для снижения нагрузки на подсистему ввода/вывода.

          на сервере используется php-акселератор eaccelerator + нгинкс на фронте

          nginx стоит фронтом к Apache? А в чем преимущество? Не проще ли было FastCGI поднять и от Апача отказаться вообще?

          которые было во времена вп2.2 и 2.3

          Разница в том, что я не использую блокировок. И на трачу процессорное время на кодирование каждого файла. В результате у меня каждый файл получается в среднем на 25% меньше (как следствие, нагрузка на дисковую подсистему уменьшается).

          В WP 2.x есть хорошая идея&nsbp;— отложенное сохранение кэша (я её еще не реализовал). Я сейчас смотрю в сторону межсессионного кэширования в памяти (shm, apc, xcache, memcached) с файловым кэшированием в качестве fallback.

          а вообще в целом при использовании плагина не заметил ни ускорения работы, ни уменьшение ни увеличение потребления процессорного времени.

          А какая была нагрузка и сколько было параллельных соединений?

          не поделитесь фичей загрузки аттачей в коменты? плагин или самописное?

          Поделюсь. Это здесь. Инструкции там же. Самописный плагин (писалось на коленке за полчаса).

          Ответить на данный комментарий

          #27
          • [Декабрь 9, 2008 20:13] Lecactus:

            все рассуждения на тему файловой системы актуальны ТОЛЬКО для юзеров которые владеют своим выделенным сервером или как минимум VDS(подозреваю что таких отсилы процентов 10).
            почему апач + нгинкс а не напрямую? я пробовал когда то и “прямой способ”, только у него масса косяков вылазила: не работал PHP на соседних доменах кроме основного, пришлось через Ж писать по новой все правила реврайта (а что то так и не заработало хотя писалось все по “инструкции для использования с ВП” - примерно похожее на такую http://df-yz.org/blog/?p=29 но где тогда видел уже не вспомню).

            apache2.2.*+php5.2.*(FastCGI)+Nginx 0.7.*+eAccelerator настроенные после долгих экспериментов с параметрами работают намного быстрее в связке + никаких глюков с “реврайтами”. статику у меня всю отдает nginx , php крутит апач

            по нагрузке в момент тестирования - было около 20человек + вездесущие роботы поисковиков. повторю уже не раз что нагрузка у меня на сервере почти нулевая уже писал тут http://blog.sjinks.org.ua/wp-file-cache/#comment-1093

            большие нагрузки я видел у себя только на старом сервере (pentum3-1000/1gb)

            кстати как по вашему на каком железе и софте крутится wordpress.com и миллионы блогов на нем? сами они рекламируют apache и litespeed для использования с ВП. (лайтспид пробовал ради эксперимента - после трех дней такнцев с бубном так и не заставил его работать правильно и снес)

            #28
          • [Декабрь 9, 2008 20:37] Vladimir:

            все рассуждения на тему файловой системы актуальны ТОЛЬКО для юзеров которые владеют своим выделенным сервером или как минимум VDS(подозреваю что таких отсилы процентов 10).

            Поэтому я и ищу другие способы.

            кстати как по вашему на каком железе и софте крутится wordpress.com и миллионы блогов на нем?

            Там всё хитро. Судя по всему, PHP у них работает в связке с nginx (FastCGI), кэширование выполняется BatCache’ем (аналог SuperCache, но для memcached). Статика отдается с sXXX.wordpress.com, который на самом деле g1.panthercdn.com (CDN, как следует из названия). На CDN стоит PWS. stats.wordpress.com тоже обслуживается nginx.

            На серверах настроена репликация (думаю, что InnoDB) и распределенное кэширование (memcached).

            хотя писалось все по “инструкции для использования с ВП”

            Я настроил, мануал: WordPress: заменяем Apache nginx’ом.

            Могу скинуть рабочие конфиги.

            #29
    • [Декабрь 7, 2008 18:53] Vladimir:

      Данные с реального сайта (extrememember.com) при высокой нагрузке:

      После такого не верится, что в WordPress тормозов нет в принципе.

      Ответить на данный комментарий

      #30
      • [Декабрь 8, 2008 20:14] Lecactus:

        что там по железу? выделенный или виртуальный хостинг? сколько посетителей обычно и в пиках? есть ли графики при использовании например суперкэша? и кстати динамичные данные некоторые в страницу можно вставлять через document.write чтобы они не кэшировались - например те же счетчики просмотров и т.п.

        Ответить на данный комментарий

        #31
        • [Декабрь 9, 2008 12:27] Vladimir:

          Хостинг выделенный, посетителей в пике около тысячи.

          Железо - 8 гиг оперативки (было 4), процессор - Intel Xeon X3320 Quad Core [4x 2.5Ghz, 6MB L2 Cache, 1333Mhz FSB] (по-моему, такой).

          Super Cache там не работает, основная причина - нагрузка создается не посетителями, а зарегистрированными пользователями (им не отдается кэш). Стоит WordPress 2.5.1 с кучей ручных заплаток (по сути - WordPress MU, но есть отличия).

          Ответить на данный комментарий

          #32
          • [Декабрь 9, 2008 16:01] Lecactus:

            любопытно: у меня athlon64-X2-4400+/2gb DDR2-800/80gb HDD ATA133 - пиковая нагрузка которую удалось сделать насильственно - около 10%. средняя 0.5% бывает кратковременная до 1секунды 5% если сразу куча народа лезет. посетителей в сутки на моем блоге около 900 в среднем + еще пара сайтов крутится и все это время я постоянно какие то эксперименты делаю на тестовых сайтах.

            что я делаю не так? сейчас у меня даже без суперкэша если его отключаю нет тормозов.

            #33
          • [Декабрь 9, 2008 16:06] Vladimir:

            900 в сутки или в короткий промежуток времени?

            #34
          • [Декабрь 9, 2008 16:10] Vladimir:

            Вкратце: есть сайт, у него 50 клиентов, владеющих своими сайтами (аналог WP MU). У каждого из этих клиентов есть свои клиенты (до 5000 на клиента + подписчики, которых я не считаю). Плюс реализация членских программ разных уровней, аффилиатов, списков рассылки, защищенного контента, и прочая муть, характерная для membership sites.

            PS - photoshopzoo.com за двое суток набрал больше тысячи клиентов, пришлось часть контента на амазон перекидывать.

            #35
          • [Декабрь 9, 2008 19:57] Lecactus:

            сорри не так понял - 1000 я так сейчас уже понял это имеется ввиду одновременных. у меня одновременных я видел ну максимум 100.

            #36
  8. [Декабрь 11, 2008 22:47] Lecactus:

    новый ахтунг: сегодня снова включил днем плагин и к вечеру заметил что блог тупит прост ооткровенно - в некоторых постах время генерации выросло до 3-4секунд. не придавал этому значения - думал нагрузка на севрер выросла - а нет. не было ничего такого. а сейчас ночью увидел плюс к этому и ужасные цифры в подвале блога и админки - выросло “потребление памяти” в 2 РАЗА. Напоминаю что на сервере используется eaccelerator. После отключения плагина ничего не изменилось и все также подтупливало и показывало потребление памяти порядка 15-16мб на морде и 27 в админке. Только после перезапуска вебсервера апачи с очисткой папки кэша eaccelerator’а все вернулось как было - быстро и потреблениепамяти резко снизилось как и было до активации плагина.

    Баг или фича?

    Ответить на данный комментарий

    #38
    • [Декабрь 11, 2008 23:00] Vladimir:

      Фича — текущая версия FileCache не использует eAccelerator. А development-версия, поддерживающая APC, xCache, eAccelerator и Zend, живет только у меня.

      Короче, к проблемам eAccelerator плагин не причастен. В том плане, что он его не использует.

      PS - если плагин был отключен, что вызывало дикое потребление памяти?

      Ответить на данный комментарий

      #39
      • [Декабрь 12, 2008 05:22] Lecactus:

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

        Ответить на данный комментарий

        #40
        • [Декабрь 12, 2008 05:29] Vladimir:

          есть ли вообще смысл в плагине этом при использовании акселераторов

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

          Ответить на данный комментарий

          #41
          • [Декабрь 12, 2008 06:36] Lecactus:

            ок. ждемс. посмотрим потом как новая версия заработает :) любопытно

            #42

RSS-фид комментариев к данной статье.
TrackBack URL: http://blog.sjinks.org.ua/wp-file-cache/trackback/

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

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

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

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