Вчера я наконец-то поднял munin и новый monit на сервере, а сегодня посмотрел на результаты мониторинга. Самое первое, что бросилось в глаза: iostat показывает очень большое количество записей (превышавшее количество чтений почти в тысячу раз).

На сервере живут четыре сайта на WordPress, два из которых (littlefox.ru и cat-tv.ru) находятся в Alexa Top 100,000 (они создают основную нагрузку на сервер).

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

С целью поэкспериментировать мы отключили SuperCache. В результате получилась такая картина. Далее

29
Июль
2009

APC (он же Alternative PHP Cache) — бесплатное расширение к PHP, предназначенное для оптимизации промежуточного кода и кэширования данных и компилированного байт-кода в разделяемой памяти.

Я заинтересовался APC с позиции его возможного применения в плагине WP File Cache, но при реализации модуля столкнулся с некоторыми особенностями (читай: ошибками), о которых документация умалчивает. Далее

6
Дек
2008

WP File Cache 1.0

Vladimir
Опубликовано в: Плагины

Появилась новая версия плагина WP File Cache.

В данной версии у плагина появился интерфейс для администратора и, как следствие, возможность "тонкой настройки".

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

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

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

  • возможность отключения кэширования (в том числе и встроенного в WordPress);
  • возможность отключения межсессионного кэширования;
  • возможность задания групп, не подлежащих межсессионному кэшированию (полезно только разработчикам, которые знают, о чём идёт речь);
  • плагин хранит свои настройки непосредственно в коде (в файле wp-content/object-cache.php). Это связано с проблемой курицы и яйца, а также с архитектурными особенностями WordPress.

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

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

По производительности плагин бьет как "голый" WordPress 2.7rc1, так и WordPress, "нагруженный" плагинами. Причем выигрыш в производительности становится всё более заметным при увеличении нагрузки на сайт (когда обмен данными с MySQL становится всё более интенсивным).

Плагин скоро появится на wordpress.org (да, у меня наконец-то дошли руки), и его можно будет скачивать прямо оттуда :-) Как следствие, у плагина появилась домашняя страница.

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

Большое спасибо Максиму Покровскому за тестирование плагина под Windows.

2
Дек
2008

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

WordPress под микроскопом

Vladimir
Опубликовано в: WordPress

Навеяло комментариями к статье "Трудности веб-разработки" и недавним копанием во внутренностях WordPress

Да, WordPress сама по себе хорошая система (особенно с точки зрения конечного пользователя): в ней можно настроить абсолютно всё (особенно, когда есть деньги и парочка толковых программистов). Но есть одно большое "но": если Вы — опытный программист и волею Фортуны Вам пришлось копаться во внутренностях этого чуда, то неизбежно в скором времени начинаете ощущать себя проктологом-патологоанатомом.

Если хочется кучу всякой гадости, вроде плагинов, редактирования страниц, темплейтов, интегрирования чего попало куда попало — естественно, за это приходится платить. Платить очень дорого.

А какое можно сделать «элегантное решение»? Чтобы оно обладало тем же функционалом? Можно только повторить монстра.

Доля истины в этом высказывании, разумеется, есть: чем универсальнее решение, тем оно монстроидальнее. Задача состоит в том, как этого монстра оптимизировать и минимизировать. Есть программисты, а есть быдлокодеры (у меня сегодня два цвета: чёрный и белый). Разница между первыми и вторыми заключается только лишь в умении использовать ресурсы серого вещества, именуемого мозгом. В результате у первых получается элегантное решение, а у вторых — Некрософт Виндовс Нерабочий Труп.

Это я всё к чему? Берём WordPress и смотрим:

MySQL: 45 запросов / 0.550 Потребление памяти: 10.1MB…

У меня немного другая статистика (наверное, сервер мощнее): 50 запросов, 0.05 сек.

Пятьдесят плюс-минус пять запросов: много ли это? Фиг его знает, может и не много, ибо всё познаётся в сравнении. Ну так давайте сравним. Я "надругался" над несчастным WordPress и просто отрубил ему кэш. Готовы?

1462 запроса и 2.02 секунды (лог запросов превышает мегабайт). Те, кто знаком с оптимизацией запросов в MySQL, ужасайтесь вместе со мной.

Можно долго спорить о том, что кэш нельзя выключать, разработчики его не зря включили и всё в том же духе. Ответ: а почему нельзя было сразу спроектировать нормально, чтобы не требовались костыли в виде кэша? По-хорошему, кэш должен использоваться как средство, дающее дополнительное ускорение приложению, но не как средство, обеспечивающее нормальную жизнедеятельность приложения. Скажем так: стимуляторы при умеренном применении могут оказать положительный эффект на человека. Но когда стимуляторы используются только для поддержания жизнедеятельности человека — это уже другая песня.

Вот так.

Но, возможно, в следующей версии

27
Ноя
2008