WP Super Cache vs MaxSite Cache: часть 2

Вторая часть статьи WP Super Cache vs MaxSite Cache.

В предыдущей части я сравнивал поведение MaxSite Cache и WP Super Cache на тестовом VDS (512 MiB RAM, 10 GB HD, Intel Xeon X3320 (1 ядро), 2.5 GHz), на котором ни операционная система, ни программное обеспечение не были специально настроены — бралась конфигурация «из коробки» и тестировалась. Одним словом, «VDS абсолютного чайника».

В этой части изменилась только конфигурация программного обеспечения: сервер настраивался на максимальную производительность.

В частности:

  • отказ от Apache в пользу nginx и от mod_php5 в пользу php-fcgi (количество FastCGI-процессов выбиралось таким образом, чтобы избежать использования файла подкачки);
  • смена ядра с linux-image-server на linux-image-virtual;
  • настройка MySQL: отказ от InnoDB (экономит примерно 100 МБ памяти), увеличение буфера ключей и т.п.;
  • установка и настройка xCache (я исходил из того, что далеко не все чувствуют себя комфортно при сборке программ из исходников, поэтому брал только готовое ПО);
  • настройка iptables для фильтрации пакетов.

Далее »

Автор: Vladimir, опубликовано в: WordPress, комментариев: 2
13
Дек
2009

Оптимизация All in One SEO Pack

Как оказалось, плагин All in One SEO Pack — один из основных источников запросов к базе данных на блогах с большим количеством страниц (page). Всё дело в том, что в All in One SEO Pack есть одна неотключаемая особенность: он пытается переписать все ссылки, которые выводятся через функцию wp_list_pages() (обычно эта функция вызывается из заголовка или подвала темы и используется для создания меню).

Вообще переписывание ссылок — это отдельная история, заслуживающая отдельной статьи. Если вкратце, то плагин берёт метаданные из поста и заменяет ими title и текст ссылки.

All in One SEO Pack: Edit Page

Что характерно, если поле Title Attribute пустое, то All in One SEO Pack вообще затрёт title ссылки.

Проблема с запросами возникает из-за того, что All in One SEO Pack читает метаданные для каждой страницы, присутствующей в результате, который вернула функция wp_list_pages(). Если в меню тридцать страниц, то в результате получим тридцать лишних запросов к базе данных. Умножаем на количество показов страниц (страниц в широком смысле, а не в терминах WordPress) и получаем большую цифру. Далее »

Автор: Vladimir, опубликовано в: Патчи, комментариев: 6
25
Ноя
2009

SQLMon: мониторинг запросов MySQL

Наверное, каждый разработчик знает, что во многих случаях плохая производительность связана с ошибками при проектировании базы данных либо неоптимальными запросами к MySQL (например, в таблице нет индекса, который мог бы использоваться для выполнения запроса, либо запрос использует ORDER BY/GROUP BY, без которых можно обойтись).

WordPress может вывести только список всех выполненных запросов — разработчику придётся запускать каждый подозрительный запрос вручную и анализировать результат. Это очень муторно и непродуктивно. SQLMon пытается помочь разработчикам, анализируя все запросы перед их выполнением, сообщая обо всём, что требует внимания.

Каждый запрос, который передаётся WordPress, анализируется (используя EXPLAIN); результаты показываются в подвале темы или панели администрирования. Лог запросов виден только администраторам, что позволяет использовать плагин даже на живых сайтах.

Одна из особенностей SQLMon — возможность выполнения EXPLAIN не только на запросах SELECT, но и UPDATE/DELETE и INSERT/REPLACE INTOAS или CREATE TABLEAS.

Перед использованием плагина рекомендую к прочтению статью Optimizing Queries with EXPLAIN.

Активация плагина: для успешной активации каталог wp-content должен быть доступен на запись — в него помещается файл db.php, который занимается отловом и анализом запросов.

Деактивация/удаление: аналогично, чтобы плагин смог удалить файл db.php, каталог wp-content должен быть доступен на запись. Тем не менее, в плагин добавлены средства контроля, позволяющие сохранить работоспособность блога, если плагин был удалён, а wp-content/db.php — нет.

Внимание:

  • плагин не будет работать с PHP 4;
  • плагин конфликтует со всеми плагинами, устанавливающими свой собственный db.php (W3 Total Cache, DB Cache, DB Cache Reloaded).

Плагин пригодится разработчикам WordPress, разработчикам плагинов и тем, а также администраторам, знающим MySQL, пытающимся понять, почему блог так медленно работает.

Домашняя страница SQLMon на wordpress.org.

Автор: Vladimir, опубликовано в: Всё подряд, комментариев: 6
23
Ноя
2009

WP Super Cache vs HyperCache vs W3 Total Cache vs MaxSite Cache

Для WordPress написано много кэширующих плагинов, предназначенных для борьбы со слабой производительностью сервера (либо кривыми руками администратора, который не в состоянии настроить PHP/MySQL). Простой пользователь зачастую задаётся вопросом: какой же из плагинов выбрать?

В данной статье я рассмотрю наиболее популярные плагины (WP Super Cache, Hyper Cache, W3 Total Cache и MaxSite Cache), а затем расскажу о результатах жестокого теста, которому я подверг все эти плагины. Далее »

Автор: Vladimir, опубликовано в: WordPress, комментариев: 43
6
Ноя
2009

SJ Hook Profiler

Разработчики плагинов WordPress и bbPress используют две функции для расширения функциональности WordPress/bbPress: это add_action() и add_filter(). Первая служит для установки обработчика некоторого события, вторая — для установки фильтра. Под хуком подразумевается обобщённое понятие (либо фильтр, либо обработчик).

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

Автор: Vladimir, опубликовано в: Всё подряд, комментариев: 4
3
Ноя
2009