Ars Longa, Vita Brevis » производительность

SQLMon для Yii

Vladimir — Tue, 22 Nov 2011 15:02:18 +0000

Расширение для анализа производительности SQL-запросов для Yii

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

Ситуацию частично исправило расширение под названием Yii DB profiler. Но остались некоторые неудобства:

Отображение запросов в порядке убывания времени выполнения — в принципе, это дело вкуса: при таком порядке сразу видны проблемные запросы. С другой стороны, лично мне более привычен хронологический порядок — так чётче прослеживается логика работы;
Prepared statements. Это просто здорово, но если повторять запрос в phpMyAdmin (например, если интересует план выполнения запроса), бывает очень муторно заменять все связанные значения. Например, для запросов вида

SELECT 't'."object_id" AS "t0_c0", 't'."ymd" AS "t0_c1", 't'."black" AS "t0_c2", 't'."brown" AS "t0_c3", 't'."yellow" AS "t0_c4",
't'."neutral" AS "t0_c5", 't'."white" AS "t0_c6", 't'."unknown" AS "t0_c7", 't'."error" AS "t0_c8", 'object'."object" AS "t1_c2",
'object'."id" AS "t1_c0"
FROM 'dnsbl_summary' 't'
LEFT OUTER JOIN 'objects' 'object' ON ('t'."object_id"='object'."id")
WHERE (((black > 0) OR (brown > 0)) AND
(((((((((ymd=:ycp0) AND (black>:ycp1)) AND (brown=:ycp2)) AND (yellow=:ycp3)) AND
(neutral>:ycp4)) AND (white>:ycp5)) AND (unknown=:ycp6)) AND (black>:ycp7)) AND
(error=:ycp8))) AND (object.enabled = 1)
LIMIT 50

заменять все :ycpXXX на их значения немного муторно. В общем случае здесь вряд ли можно что-то сделать — заполнители параметров могут быть любыми (и даже позиционными), поэтому тупое использование str_replace может наделать делов.

Лично мне список запросов нужен обычно только для двух вещей:

Оценка работы механизмов кэширования;
Оценка плана выполнения запроса, составленная оптимизатором.

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

В результате, взяв за основу плагин Александра, я портировал SQLMon на Yii.

В результате получилось расширение, позволяющее получать планы выполнения запросов в реальном времени.

Поддерживаются MySQL и SQLite, в планах поддержка PgSQL (там не всё просто, ибо Postgres выполняет запрос, что может привести к интересным последствиям при использовании INSERT/UPDATE/DELETE; как следствие, придётся использовать вложенные транзакции).

Вывод результатов осуществляется либо при помощи виджета:

$this->widget(
'ext.sqlmon.components.SQLMon'
array(
'explain' => true, // Показывать план выполнения запроса
'backtrace' => true, // Показывать трассу вызовов
'dsn' => true, // Показывать DSN соединения (может быть полезно при использовании нескольких БД)
'cssFile' => null, // Эстеты могут задать свой файл стилей
)
);

Либо при помощи Log Route:

return array(
'components' => array(
'log' => array(
'routes' => array(
array(
'class' => 'ext.sqlmon.components.SQLMonLogRoute',
'showExplain' => true, // Показывать план выполнения
'showDsn' => true, // Показывать DSN соединения
'showBacktrace' => true, // Показывать трассу вызовов
),
array(
'class' => 'ext.sqlmon.components.SQLMonFileLogRoute',
'logFile' => 'sqlmon.log',
'showExplain' => true, // Показывать план выполнения
'showDsn' => true, // Показывать DSN соединения
'showBacktrace' => true, // Показывать трассу вызовов
),
),
)
),
);

SQLMonLogRoute наследуется от CWebLogRoute, но, как и CProfileLogRoute, отказывается выдавать данные для AJAX-запросов.

SQLMonFileLogRoute наследуется от CFileLogRoute и, как следствие, воспринимает все параметры конфигурации последнего.

Для того, чтобы протоколирование нормально работало, сообщения от SQLMon попадают в общий протокол и, как следствие, видны при использовании CWebLogRoute (в этом случае выдаётся минимум информации).

Результаты работы выглядят примерно так (пример приведён для SQLite):

Реализовано всё через собственный класс PDO, поэтому для использования SQLMon нужно в файл конфигурации добавить такие строки:

return array(
'import' => array(
'ext.sqlmon.components.*',
),

'components' => array(
'db' => array(
// ...
'pdoClass' => 'SQLMonPDO',
),
),
);

Реализация просмотра выполнения плана выполнения запроса осуществляется при помощи класса-наследника от PDOStatement и переопределения метода PDO::prepare().

Планы на будущее:

поддержка PostgreSQL;
возможность расширения классов SQLMonPDO и SQLMonPDOStatement (возможно, придётся позаимствовать некоторые идеи из Kohana);
наследование SQLMon_Explainer_Base от CComponent, что даст дополнительные плюшки для расширяемости;
более красивая реализация функции SQLMon::arr2pre(), что позволит рисовать красивые ASCII-таблички;
возможная поддержка FireBug;
протоколирование в HTML-файл;
информация профайлера MySQL (нужность пока под большим вопросом);
рефакторинг, написание документации

SQLMon 0.1 for Yii — скачать бесплатно без регистрации без смс

При использовании материалов блога наличие активной не закрытой от индексирования ссылки на источник обязательно.

KSES в WordPress: можно ли проще?

Vladimir — Thu, 10 Feb 2011 06:07:09 +0000

Регулярные выражения против DOM XML

Вчера мне довелось разбираться с тем, как работает KSES в WordPress.

KSES (рекурсивный акроним от KSES Strips Evil Scripts) — подсистема в WordPress (изначально написанная Ulf Harnhammar), предназначенная для проверки и очистки текста, введённого пользователем: она позволяет задать список допустимых тэгов, стилей и протоколов и на основе этих параметров убрать из текста пользователя всё, что им не соответствует.

KSES является довольно стабильной подсистемой; что немаловажно, KSES работает. Работает — не трогай, а то сломаешь…

Лично мне в KSES не нравится использование регулярных выражений. Одна из причин — теория разработки компиляторов. Известно, что HTML — это грамматика второго типа в иерархии Хомского (контекстно-свободная грамматика), а регулярные выражения — грамматика третьего типа (регулярная грамматика). Грамматика второго типа является более сложной, нежели грамматика третьего типа. Как следствие, описать более простой грамматикой то, что соответствует более сложной, очень трудно (вряд ли возможно на 100%, но это моё мнение).

Что плохо, среди тестов WordPress я не нашёл тестов для KSES. Что может означать, что, вероятно, никто из разработчиков не строил и не проверял граф путей в KSES; как следствие, не гарантии, что при граничных условиях всё будет работать нормально.

Другая причина, по которой я не люблю регулярные выражения — это скорость: особой производительностью они не отличаются. Хотя с другой стороны, объёмы проверяемого текста не так велики, чтобы KSES оказывал существенное влияние на производительность.

Каковы альтернативы? Обзор.

На мой взгляд, самая удобная альтернатива — использование DOM XML и работа с полученным деревом. Тем более, что в PHP есть соответствующая поддержка. А парсер на C в любом случае быстрее парсера на PHP.

Парсер DOM XML в PHP позволяет работать даже с некорректным HTML. Что означает, что он берёт на себя решение проблемы с неправильно закрытыми или незакрытыми тэгами. Парсер понимает HTML entities и преобразует их в нормальный текст. Что означает, что не нужно возиться с разными форматами записи entities и переводить их к одному виду (чему в KSES уделено не мало кода). И так далее.

Для проверки некоторых идей я написал небольшой класс, который делает почти то же самое, что и KSES, только иначе Я ни в коем случае не рассматриваю его как замену KSES.

class Xex
{
private $protocols = array();
private $tags = array();
private $css = array();

private $strip_comments = true;
private $strip_script_text = true;
private $strip_style_text = true;

private $script_text = true;
private $style_text = true;

private $trim_text = false;

public function __construct(array $tags = null, array $protocols = null, array $css = null)
{
if (null !== $tags) $this->tags = $tags;
if (null !== $protocols) $this->protocols = array_combine($protocols, $protocols);
if (null !== $css) $this->css = array_combine($css, $css);
}

protected function checkProtocols($str)
{
$s = str_replace(array("\r", "\n", "\t", ""), '', $str);
$s = explode(':', $s, 2);

// See http://tools.ietf.org/html/rfc3986#section-3.1
if (preg_match('/^[a-z][a-z0-9+.-]*$/', $s[0]) && !isset($this->protocols[$s[0]])) {
return '';
}

return $str;
}

protected function sanitizeCss($css)
{
$css = str_replace(array("\n","\r","\t"), '', $css);

if (preg_match('![\\(&=}]|/\\*!', $css)) {
return '';
}

$arr = explode(';', trim($css));

$css = '';
foreach ($arr as $x) {
$x = trim($x);
if ($x) {
$found = false;
if (false === strpos($x, ':')) {
$found = true;
}
else {
$parts = explode(':', $x, 2);
if (isset($this->css[rtrim($parts[0])])) {
$found = true;
}
}

if ($found) {
$css .= $x . ';';
}
}
}

return $css;
}

protected function parseDOM(DOMNode $el, DOMNode $new)
{
switch ($el->nodeType) {
case XML_ELEMENT_NODE:
$prefix = $el->prefix ? ($el->prefix . ':') : '';
$tag = $prefix . $el->tagName;

if (isset($this->tags[$tag])) {
$n = $new->appendChild($el->cloneNode(false));
if ($el->hasAttributes()) {
$attrs = $this->tags[$tag];
foreach ($el->attributes as $a) {
if (!isset($attrs[$a->name])) {
$n->removeAttribute($a->name);
}
elseif ('style' == $a->name) {
$css = $this->sanitizeCss($a->value);
if ($css != $a->value) {
$n->setAttribute($a->name, $css);
}
}
elseif (in_array($a->name, array('xmlns', 'profile', 'href', 'src', 'cite', 'classid', 'codebase', 'data', 'usemap', 'longdesc', 'action'))) {
$s = $this->checkProtocols($a->value);
if ($s != $a->value) {
$n->setAttribute($a->name, $s);
}
}
}
}
}
else {
if ($tag == 'script' && $this->strip_script_text || $tag == 'style' && $this->strip_style_text) {
return;
}

$n = $new;
}

if ($el->hasChildNodes()) {
foreach ($el->childNodes as $e) {
$this->parseDOM($e, $n);
}
}

return;

case XML_TEXT_NODE:
if (!$this->trim_text) {
$new->appendChild($el->cloneNode(true));
}
else {
$new->appendChild(new DOMText(trim($el->wholeText)));
}

return;

case XML_CDATA_SECTION_NODE:
$new->appendChild($el->cloneNode(true));
return;

case XML_COMMENT_NODE:
$parent = $el->parentNode;
if ($parent && $parent->tagName) {
$prefix = $parent->prefix ? ($parent->prefix . ':') : '';
$tag = $prefix . $parent->tagName;

if ('style' == $tag && $this->style_text || 'script' == $tag && $this->script_text) {
$new->appendChild(new DOMText($el->data));
return;
}
}

if (!$this->strip_comments) {
$new->appendChild($el->cloneNode(true));
}

return;

default:
break;
}
}

public function sanitize($s)
{
$dom = new DOMDocument();
$dom->recover = true;
$dom->strictErrorChecking = false;
$dom->substituteEntities = true;
$dom->resolveExternals = false;
$dom->formatOutput = false;

$old = libxml_use_internal_errors(true);

$s = str_replace(chr(0), '', $s);
$s = preg_replace('!<([^a-z\\?\\!/])!i', '<$1', $s);
$s = preg_replace('!<((?:[\\?\\!/]\\s*)?[a-z][^>]*)(?=<)!i', '<$1', $s);
@$dom->loadHTML($s);
libxml_use_internal_errors($old);

$new = $dom->createDocumentFragment();
$new->appendChild(new DOMElement('wrap'));
$this->parseDOM($dom->documentElement, $new->firstChild);
$dom->replaceChild($new, $dom->documentElement);
$s = $dom->saveXML($dom->documentElement, LIBXML_NOEMPTYTAG);

return substr($s, strpos($s, '') + 6, -7);
}
}
?>

Менее 200 строк против почти полутора тысяч.

На 45-килобайтном документе DOM быстрее KSES от 5 до 9 раз.
На 90-килобайтном документе DOM быстрее KSES от 6 до 9 раз.
На 180-килобайтном документе DOM быстрее KSES от 9 до 10 раз.

Производительность зависит от количества тэгов и стилей (разбор стилей реализован практически одинаково). Например, на домашней странице Google XEX может опережать KSES в 25 раз; если же соединить домашнюю страницу Google саму с собой 4 раза, разница во времени сокращается.

На домашней странице WordPress разница в 7 раз.

На этой странице разница в 4 раза.

Всё-таки KSES очень медленный…

Блокировки транзакций InnoDB при удалении данных из таблицы

Vladimir — Sat, 05 Feb 2011 16:01:16 +0000

Lock wait timeout exceeded; try restarting transaction

Ситуация: есть несколько физических почтовых серверов (PowerMTA), отсылающих более четырёх миллионов сообщений в сутки. Есть виртуальный сервер базы данных (причём не очень мощный), на котором крутится MySQL с InnoDB; в базу данных пишутся логи доставки/не доставки сообщений и ведётся статистика по IP-адресам, VMTA и доменам. Попутно выполняется классификация и анализ hard и soft bounces. База за день увеличивается примерно на 5 гигабайт. Часть логов недельной давности удаляется.

Так как с базой (на запись) работает несколько клиентов, структура таблиц/индексы выбраны таким образом, чтобы обеспечить максимальную скорость добавления записей и минимум блокировок.

Проблема возникла с ведением статистики.

Есть таблица такой структуры:

CREATE TABLE log (
id BIGINT UNSIGNED NOT NULL PRIMARY KEY AUTO_INCREMENT,
ymd INTEGER NOT NULL,
domain VARCHAR(255) NOT NULL,
vmta VARCHAR(255) NOT NULL,
ip VARCHAR(45) NOT NULL,
deliveries TINYINT UNSIGNED NOT NULL,
bounces TINYINT UNSIGNED NOT NULL,
transients TINYINT UNSIGNED NOT NULL,
pmta_bounces TINYINT UNSIGNED NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

В таблицу заносятся данные о доставке сообщений — выполняется это триггерами post insert: при доставке сообщения в таблицу заносится запись (NULL, DATE_FORMAT(NOW(), "%Y%m%d"), domain, vmta, ip, 1, 0, 0, 0, 0), при получении hard bounce — (NULL, DATE_FORMAT(NOW(), "%Y%m%d"), domain, vmta, ip, 0, 1, 0, 0, 0) — всё это выполняется довольно быстро, жалоб нет.

Проблемы начинаются при обработке данного лога. Что нужно сделать: подсчитать SUM(deliveries), SUM(bounces), SUM(transients), SUM(pmta_bounces) для каждой четвёрки (ymd, domain, vmta, ip). Данная операция выполняется каждые десять минут. Обработанные данные из таблицы log нужно удалить.

В терминах SQL это выглядит примерно так:

CREATE PROCEDURE populate_stats_daily()
BEGIN
DECLARE max_id BIGINT UNSIGNED;

START TRANSACTION;
SELECT MAX(id) INTO max_id FROM log;
INSERT INTO stats_daily (ymd, domain, vmta, ip, deliveries, bounces, transients, pmta_bounces)
SELECT
ymd, domain, vmta, ip,
SUM(deliveries) AS deliveries, SUM(bounces) AS bounces,
SUM(transients) AS transients, SUM(pmta_bounces) AS pmta_bounces
FROM log
WHERE id <= max_id
GROUP BY ymd, domain, vmta, ip
ORDER BY NULL
ON DUPLICATE KEY UPDATE
deliveries = deliveries + VALUES(deliveries),
bounces = bounces + VALUES(bounces),
transients = transients + VALUES(transients),
pmta_bounces = pmta_bounces + VALUES(pmta_bounces);

DELETE FROM log WHERE id <= max_id;
COMMIT;
END

Проблема наступает при выполнении оператора DELETE: SHOW PROCESSLIST показывает состояние Updating минуты полторы, после чего в лог пишется печально известное сообщение Lock wait timeout exceeded; try restarting transaction и транзакция откатывается. При этом количество записей в таблице log всего лишь порядка 80,000.

В принципе, проблема с DELETE давно известна: в InnoDB удаление строк весьма тормозное. По всей видимости, это усугубляется тем, что в таблицу постоянно идёт запись новых данных. Руководство пользователя объясняет суть проблемы.

А решение таково: заводим дополнительную колонку в таблице (processed) и создаём по ней индекс. DELETE FROM log WHERE id <= max_id заменяем на UPDATE log SET processed = 1 WHERE id <= max_id, что выполняется гораздо быстрее. Затем заводим еще одну транзакцию, в которой удаляем строки с processed = 1.

Но в один заход все строки удалить не получится, поэтому придётся идти на хитрость:

BEGIN
DECLARE cnt BIGINT UNSIGNED;

/* ... */

REPEAT
START TRANSACTION;
DELETE FROM log WHERE processed = 1 LIMIT 1000;
SELECT ROW_COUNT() INTO cnt;
COMMIT;
UNTIL cnt = 0 END REPEAT;
END

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

Вполне возможно, что можно обойтись без дополнительной колонки и использовать REPEAT … END REPEAT с DELETE FROM log WHERE id <= max_id, но текущий вариант работает, кушать не просит, блокировок не создаёт. А наше основное правило — si fractum non sit, noli id reficere.

WordPress: кэширование средствами nginx

Vladimir — Fri, 10 Dec 2010 12:08:15 +0000

Уменьшение потребления ресурсов во много раз

Много было сказано про кэширование в WordPress… Сегодня я хочу рассказать о действительно эффективном методе, позволяющем сильно снизить нагрузку.

Метод основан на использовании кэша FastCGI web-сервера nginx.

Идея состоит в генерации статических страниц и отдачи их пользователям, не имеющим cookie комментатора. Зарегистрированным пользователям, а также комментаторам всегда отдаётся свежая страница. Так как читателей, ни разу не оставлявших комментарий, как правило, гораздо больше, чем комментаторов, то подобный использование кэша позволяет значительно снизить нагрузку на WordPress/PHP. Знакомые с принципом работы WP Super Cache заметят, что WPSC использует тот же принцип работы.

В чем же преимущество перекладывания работы на Web-сервер (nginx)?

PHP — интерпретируемый язык. Как следствие, аналогичный код на компилируемом языке будет во много раз быстрее.
WordPress во многом bloatware От момента начала загрузки страницы до окончания выполнения стадии init выполняется очень много «лишнего» кода.
В зависимости от нагрузки на сервер от запроса страницы до выполнения PHP-кода может пройти некоторое время: всё зависит от загруженности PHP (если все дочерние процессы PHP заняты обработкой запроса, новому запросу придётся ждать освобождения одного из процессов. Если за приемлемое время ни один процесс не освободился, пользователь видит сообщение о печально знаменитой ошибке 504).
Когда обслуживанием кэша занимается web-сервер, шансы на возникновение подобной ситуации

Теперь переходим от теории к практике.

fastcgi_cache_path /var/lib/nginx/myblog levels=2 keys_zone=myblog:10m max_size=512m inactive=20m;
server {
server_name example.com;
root /path/to/blog;
index index.php;
if ($http_cookie ~* "comment_author_|wordpress_(?!test_cookie)|wp-postpass_" ) {
set $do_not_cache 1;
}
fastcgi_cache_bypass $do_not_cache;
fastcgi_no_cache $do_not_cache;
fastcgi_pass_header Cookie;
fastcgi_cache myblog;
fastcgi_cache_key $request_method|$host|$request_uri;
fastcgi_cache_valid 301 8h;
fastcgi_cache_valid 404 1h;
fastcgi_cache_valid 200 15m;
if ($http_user_agent !~ FeedBurner) {
# Здесь идут перенаправления для FeedBurner
}
error_page 404 = @wordpress;
log_not_found off;
location ^~ /files/ {
rewrite /files/(.+) /wp-includes/ms-files.php?file=$1 last;
}
location ~ ^/(wp-admin/.*\.php|wp-login\.php|wp-register\.php|(feed|comment/feed)(/.*)?)$ {
try_files $uri @wordpress;
set $do_not_cache 1;
fastcgi_cache_bypass 1;
fastcgi_no_cache 1;
fastcgi_pass unix:/dev/shm/php-fcgi.sock;
fastcgi_index index.php;
include /etc/nginx/fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}
location @wordpress {
include /etc/nginx/fastcgi_params;
fastcgi_param SCRIPT_NAME /index.php;
fastcgi_param SCRIPT_FILENAME $document_root/index.php;
fastcgi_index index.php;
fastcgi_pass unix:/dev/shm/php-fcgi.sock;
if ($do_not_cache != "1") {
add_header Vary Cookie;
}
}
location ~ \.php$ {
include /etc/nginx/fastcgi_params;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
try_files $uri @wordpress;
fastcgi_pass unix:/dev/shm/php-fcgi.sock;
if ($do_not_cache != "1") {
add_header Vary Cookie;
}
}
location ^~ /blogs.dir/ {
internal;
root /path/to/blog/wp-content/;
}
}

Документация по использованию FastCGI в nginx приведена здесь, поэтому я не буду подробно останавливаться на том, что конкретно каждая директива делает.

Основная магия происходит в строка 8—10: здесь определяются условия, при которых отдаётся свежая страница. В данном случае проверяется наличие авторизационных cookie и cookie комментатора. Важно, чтобы в случае отказа от кэширования переменная $do_not_cache устанавливалась в 1.

Строка 16 задаёт ключ, по которому страница доступна в кэше. В ключе присутствует $request_method, чтобы различать запросы GET и HEAD (для HEAD данные не возвращаются, только заголовки).

Строки 17—19 задают время жизни кэша в зависимости от кода ответа. Чем больше время жизни, тем реже будет обновляться информация для незарегистрированных пользователей.

В строке 32 задаётся маска для страниц, которые не должны кэшироваться (например, админка, страницы логина и регистрации, фиды).

Так как содержимое страницы может отличаться в зависимости от cookie пользователя, в строках 49 и 59 для закэшированных страниц принудительно выставляется заголовок Vary: Cache. Если используются другие правила (например, фильтрация по User-Agent), нужно добавлять соответствующее правило.

Строки 21—23: подробнее описано в статье «Перенаправление RSS в WordPress на FeedBurner для nginx»

Строки 28—30, 63—66 подробнее описаны в статье «WordPress MultiSite, nginx и X-Accel-Redirect»

Вроде бы ничего не забыл. Теперь о том, какую производительность мы получаем:

$ ab -n 10000 -c 100 http://blog.sjinks.pro/
Server Software: nginx
Server Hostname: blog.sjinks.pro
Server Port: 80

Document Path: /
Document Length: 50294 bytes

Concurrency Level: 100
Time taken for tests: 46.925 seconds
Complete requests: 10000
Failed requests: 0
Write errors: 0
Total transferred: 504940000 bytes
HTML transferred: 502940000 bytes
Requests per second: 213.10 [#/sec] (mean)
Time per request: 469.254 [ms] (mean)
Time per request: 4.693 [ms] (mean, across all concurrent requests)
Transfer rate: 10508.28 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 16 94 76.9 94 3125
Processing: 118 373 81.7 360 1334
Waiting: 17 69 38.5 57 422
Total: 156 467 105.0 445 3535

Percentage of the requests served within a certain time (ms)
50% 445
66% 454
75% 471
80% 494
90% 541
95% 589
98% 655
99% 768
100% 3535 (longest request)

Сервер зафлудили 10,000 запросами в 100 параллельных потоков. Сервер выдал практически полгигабайта за 47 секунд; в среднем сервер обрабатывал 213 запросов в секунду, при этом 99% запросов были обработаны за 768 мс (при том, что на сервере несколько сайтов в Alexa Top 100,000)! Нагрузка на сервер была минимальной (изменений Load Average замечено не было).

UPDATE: есть один небольшой нюанс: CAPTCHA. Если вы их используете, убедитесь, что они работают. Дело в том, что страница со статьёй будет отдаваться непосредственно из кэша nginx, PHP загружаться не будет. Поэтому если CAPTCHA полагается на использование сессии, она может работать неправильно. Здесь всё зависит от используемого плагина.

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

Vladimir — Sun, 13 Dec 2009 08:23:41 +0000

Тест страничных кэшей на грамотно настроенном сервере

Вторая часть статьи 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 для фильтрации пакетов.

Методика тестирования осталась прежней: карта сайта преобразовывалась в список адресов, на этот список натравливался siege, а я присматривал за сервером и вносил коррективы в конфигурацию ПО (да, с первого раза трудно всё настроить идеально).

Чтобы убедиться, что новая конфигурация не хуже старой, я полностью отключил кэширование и имитировал 50 одновременных посетителей в течение 15 минут. На момент выполнения теста у сервера было свободно 348.5 МиБ памяти.

	Голый WordPress
Количество транзакций	4,825
Доступность сервера	99.98%
Объём данных, МБ	28.32
Среднее время ответа, с	9.23
Частота транзакций в секунду	5.36
Пропускная способность, МБ/с	0.03
Коэффициент параллельности	49.50
Максимальная длина транзакции, с	30.76
Минимальная длина транзакции, с	1.15
Максимальная загрузка процессора (system/user)	25.72%/68.39%
Load Average	40.81
Примерное потребление памяти, МиБ	414

Данные загрузки/потребления памяти очень приблизительны. Хотя вряд ли пользователи станут ждать по 9 секунд загрузку страницы, радует, что сервер не ответил только на один запрос и не ушел в нокдаун. Простая экстраполяция показывает, что сервер выдержит примерно 463,000 обращения к PHP-страницам в сутки.

Мы убедились, что новая конфигурация вполне жизнеспособна (старой до неё, как до Китая в неудобной позе), переходим к тестированию плагинов.
Тестирование проходило в 30 и 75 потоков. Я не разделял фазы построения и использования кэша.

	MaxSite Cache (30 потоков)	MaxSite Cache (75 потоков)	WP Super Cache (30 потоков, HALF ON)	WP Super Cache (30 потоков)	WP Super Cache (75 потоков)
Количество транзакций	176,684	182,604	5,069	198,160	189,686
Объём данных, МБ	1,062.24	1,099.60	29.99	1,202.95	1,147.33
Среднее время ответа, с	0.13	0.34	5.30	0.10	0.29
Частота транзакций в секунду	196.36	203.00	5.64	220.20	210.95
Пропускная способность, МБ/с	1.18	1.32	0.03	1.34	1.28
Коэффициент параллельности	25.42	69.32	29.85	23.05	62.16
Максимальная длина транзакции, с	21.08	26.12	15.06	22.78	25.03
Минимальная длина транзакции, с	0.00	0.00	0.48	0.00	0.00
Load Average	1.8	2.2	30.1	1.3	1.65

Краткие выводы: на грамотно настроенном сервере лидирует WP Super Cache — и по скорости, и по создаваемой нагрузке. Это связано с тем, что задача по отдаче закэшированного контента переложена на web-сервер. Так как web-сервер справляется со статикой быстрее, чем с динамикой, в результате получаем рост производительности и снижение нагрузки.

Если по той или иной причине WP Super Cache не может работать в режиме Full On, то MaxSite Cache будет всё же предпочтительнее — ввиду своей простоты он обладает исключительным быстродействием.

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

Vladimir — Wed, 25 Nov 2009 05:35:33 +0000

Избавляемся от лишних запросов к базе данных

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

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

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

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

К счастью, у проблемы есть решение. Я даже о нём писал — ещё год назад — Секреты update_postmeta_cache(): Способ увеличения производительности при чтении метаданных записей.

В файле all-in-one-seo-pack/all-in-one-seo-pack.php нужно заменить несколько строчек.

В районе 642 строки есть такой код:
1. if($aioseop_options['aiosp_enabled']){
2. add_action('wp_list_pages', 'aioseop_list_pages');
4. }
Нужно вместо add_action поставить add_filter:
1. if($aioseop_options['aiosp_enabled']){
2. add_filter('wp_list_pages', 'aioseop_list_pages');
4. }
А если функциональность с переписыванием title ссылок вообще не нужна, то вместо замены слова проще закомментировать всю строку.
Затем нужно найти функцию aioseop_list_pages():
1. // The following two functions copied entirely and modified slightly from Sarah G's Page Menu Editor, http://wordpress.org/extend/plugins/page-menu-editor/
2. function aioseop_list_pages($content){
3. $url = preg_replace(array('/\//', '/\./', '/\-/'), array('\/', '\.', '\-'), get_option('siteurl'));
4. $pattern = '/
5. ([^<]+)<\/a>/i';

return preg_replace_callback($pattern, "aioseop_filter_callback", $content);

}

и переписать её:

function aioseop_list_pages($content){
$matches = array();
if (preg_match_all('/

, $content, $matches)) {
update_postmeta_cache(array_values($matches[1]));
unset($matches);
$pattern = '/

([^<]+)<\/a>/i';
return preg_replace_callback($pattern, "aioseop_filter_callback", $content);
}

return $content;
}

Это поможет избавиться от лишних запросов.

Патч в формате unified diff (внимание, формат концов строк может различаться):

--- all_in_one_seo_pack.orig.php 2009-12-16 09:37:23.000000000 +0200
+++ all_in_one_seo_pack.php 2009-12-17 06:00:32.000000000 +0200
@@ -632,7 +632,7 @@
}

if($aioseop_options['aiosp_enabled']){
- add_action('wp_list_pages', 'aioseop_list_pages');
+ add_filter('wp_list_pages', 'aioseop_list_pages');
remove_action( 'wp_head', 'rel_canonical' );
}

@@ -688,11 +688,17 @@

// The following two functions copied entirely and modified slightly from Sarah G's Page Menu Editor, http://wordpress.org/extend/plugins/page-menu-editor/
function aioseop_list_pages($content){
- $url = preg_replace(array('/\//', '/\./', '/\-/'), array('\/', '\.', '\-'), get_option('siteurl'));
+ $matches = array();
+ if (preg_match_all('/

(\d+)/i', $content, $matches)) {
+ update_postmeta_cache(array_values($matches[1]));
+ unset($matches);
$pattern = '/

(\d+)([^\"]*)">([^\"]+)" title="([^\"]+)">([^<]+)<\/a>/i';
return preg_replace_callback($pattern, "aioseop_filter_callback", $content);
}

+ return $content;
+ }
+
function aioseop_filter_callback($matches) {
global $wpdb;
if ($matches[1] && !empty($matches[1])) $postID = $matches[1];

UPDATE: обновил патч, теперь он подходит для All in One SEO Pack 1.6.8.2 и поместил патч на форум поддержки.

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

Vladimir — Fri, 06 Nov 2009 10:59:55 +0000

Сравнение различных плагинов кэширования для WordPress

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

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

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

Поехали.

WP Super Cache написан Donncha O’Caoimh, одним из разработчиков WordPress. Про своё отношение к этому плагину я уже писал. Плагин разрабатывался как замена WP-Cache. Ключевой особенностью плагина является генерация статических HTML-страниц таким образом, что они будут отдаваться Web-сервером — минуя PHP.
Hyper Cache. С ним я тоже сталкивался, и какое-то время плагин стоял у меня на сайте. Плагин написан гораздо проще, чем WP Super Cache и имеет более высокий рейтинг на wordpress.org.
W3 Total Cache — новое слово в кэшировании. Поддерживает сжатие скриптов, CSS, кэш для базы данных, работу с CDN и многое другое.
MaxSite Cache — отечественная разработка, при этом платная. Я тестировал Lite-версию, так как покупать полную версию чисто для тестирования желания нет. По словам автора, выйдет абсолютным победителем при сравнении с WP Super Cache и компанией.

Для теста была взята машина такое конфигурации: Intel(R) Xeon(R) CPU X3320 @ 2.50GHz, 4 ядра, 3 MiB кэш, 8 GiB DDR-2 RAM, 2×500 GB SATA, RAID1 (ARC-1210 4-Port PCI-Express to SATA RAID Controller), 82572EI Gigabit Ethernet Controller.
Операционная система: Ubuntu 9.10 64-bit Server Edition
Веб-сервер: nginx 0.8.19
PHP: 5.2.10.dfsg.1-2ubuntu6.1 (FastCGI) + xCache 1.2.2-5, 75 процессов.

На тестируемой странице 25 несложных запросов, время их выполнения — 0.00993 сек.

На сайт натравливался ApacheBench — 10,000 запросов в 100…500 потоков. Это создаёт весьма приличную нагрузку, так как запросы идут один за другим.

Базовая нагрузка — 100 параллельных потоков. Я увеличивал количество потоков до тех пор, пока web-сервер не стал отдавать ответ, отличный от 200. Более 500 потоков не тестировал.

	WordPress	WP Super Cache 0.9.7		Hyper Cache 2.6.2		MaxSite Cache Lite			W3 Total Cache 0.8
Количество потоков	100	100	500	100	250	100	500	130	100	130
Время тестирования, с	677.442	1.115	1.079	18.736	8.633	3.291	2.501	2.992	21.284	21.086
Количество ошибок	0	0	0	0	3663	0	2713	0	0	0
Скорость, запрос/с	14.76	8967.28	9268.36	544.20	1158.30	3038.98	3997.80	3341.72	469.84	474.25
Среднее время обработки запроса, мс	6774.423	11.152	53.947	183.757	215.833	32.906	125.069	38.902	212.838	274.116
Среднее время обработки запроса по всем потокам, мс	67.744	0.112	0.108	1.838	0.863	0.329	0.250	0.299	2.128	2.109
Скорость передачи, Кбайт/с	175.12	106154.90	109865.55	6393.68	8754.04	35537.15	34413.87	39075.95	4928.74	4974.58
Порог завершения 95% запросов, мс	9188	11	27	394	268	52	91	58	344	364

То, что не вошло в таблицу: средняя загрузка системы (load average) при тесте голого WordPress зашкаливала за 60. При тесте WP Super Cache и MaxSite Cache я не успевал ее измерить (была ничтожной). С Hyper Cache и W3 Total Cache загрузка доходила до где-то 10. Так что кэширование работает и выполняет свою работу — снижает нагрузку на сервер.

«Голый» WordPress тестировать более, чем со 100 потоками смысла нет

В ходе тестирования выяснился абсолютный лидер — WP Super Cache. Скорость отдачи кэшированных страниц поистине фантастическая — почти 800 мегабит/сек. Хотя такая скорость — это больше заслуга nginx.

MaxSite Cache Lite на 100 параллельных потоках проиграл WP Super Cache практически в пять раз! Причина понятна: WP Super Cache создает статические файлы так, что web-сервер их может отдавать клиенту без привлечения PHP-интерпретатора. А статические запросы при прочих равных всегда быстрее динамических. Так что платить 30 WMZ за полную версию MaxSite Cache я пока не готов

Среди остальных плагинов MaxSite Cache выигрывает благодаря свой простоте: минимум проверок, никаких регулярных выражений и лишних подключаемых файлов. Но даже такой подход не спасёт от хорошего SlashDot-эффекта: какой-то процент пользователей будет видеть ошибку сервера, для других возрастёт время генерации страницы. Это касается и остальных плагинов. Мораль: подключение PHP-интерпретатора — дорогое удовольствие.

По поводу масштабируемости: более 130 потоков не пережил ни один кэш (кроме WP Super Cache).

Аутсайдером, на мой взгляд, оказался W3 Total Cache — при почти одинаковой с Hyper Cache нагрузкой на сервер, время отдачи страниц было значительно выше. Хотя если бы тест был не таким искусственным, то производительность W3 Total Cache могла быть и более высокой. Хотя во многом W3 Total Cache делает то, что опытный системный администратор может настроить на уровне сервера.

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

Кстати, даже при хорошей дисковой подсистеме, но при малом объеме оперативной памяти при большом объеме кэша могут возникать проблемы: например, если дисковый кэш у операционной системы мал, то при интенсивном равномерном обращении к разным страницам может возникнуть большая дисковая активность.

Вообще, как показывает мой опыт, прежде чем использовать плагин кэширования страниц, имеет смысл все же грамотно настроить сервер (обращайтесь). Например, если вместо Apache поставить nginx, можно освободить довольно много драгоценной памяти (prefork у Apache — это весьма сильный убийца производительности); если увеличить размер буфера ключей MySQL, можно добиться уменьшения дисковой активности. Если поставить opcode cacher (APC, xCache, eAccelerator), то можно значительно снизить затраты на перекомпиляцию PHP-кода и уменьшить время отклика системы. Если использовать оптимизатор, встроенный в eAccelerator, то можно повысить производительность PHP-кода. Анализ производительности MySQL-запросов и знание принципов работы оптимизатора помогут переписать слабые запросы/добавить отсутствующие индексы в базу данных. Простор для действий довольно-таки большой. И динамика страниц остаётся

PHP: красота кода сказывается на производительности: часть 2

Vladimir — Wed, 07 Oct 2009 01:23:25 +0000

Как же всё запущено

В прошлой части:

if быстрее, чем switch;
echo быстрее, чем print;
явная проверка на (не)нулевое значение медленнее, чем неявная.

А также:

константные выражения, которые могут быть вычислены на этапе компиляции, не вычисляются;
PHP не умеет удалять неиспользуемый код на этапе компиляции.

Продолжим.

Конкатенация или переменные внутри строки?

	Конкатенация	Переменные внутри строки
Код	$tpl = "str2"; $text = 'str1 ' . $tpl . " str3\n"; echo $text; ?>	$tpl = "str2"; $text = "str1 {$tpl} str3\n"; echo $text; ?>
Результат	line # op fetch ext return operands ------------------------------------------------------------------------------- 2 0 ASSIGN $tpl, 'str2' 3 1 CONCAT ~1 'str1 ', $tpl 2 CONCAT ~2 ~1, ' str3\n' 3 ASSIGN $text, ~2 4 4 ECHO $text 6 5 RETURN 1 6* ZEND_HANDLE_EXCEPTION	line # op fetch ext return operands ------------------------------------------------------------------------------- 2 0 ASSIGN $tpl, 'str2' 3 1 INIT_STRING ~1 2 ADD_STRING ~1 ~1, 'str1 ' 3 ADD_VAR ~1 ~1, $tpl 4 ADD_STRING ~1 ~1, ' str3\n' 5 ASSIGN $text, ~1 4 6 ECHO $text 6 7 RETURN 1 8* ZEND_HANDLE_EXCEPTION

Вывод: конкатенация быстрее, и, как показал тест (путём замены echo $text; на echo memory_get_usage();), потребляет меньше памяти.

Цикл со счётчиком: `while` или `for`?

	`for`	`while`
Код	for ($i=0; $i<1000; ++$i) { } ?>	$i = 0; while ($i<1000) { ++$i; } ?>
Результат	line # op fetch ext return operands ------------------------------------------------------------------------------- 2 0 ASSIGN $i, 0 1 IS_SMALLER ~1 $i, 1000 2 JMPZNZ 5 ~1, ->6 3 PRE_INC $i 4 JMP ->1 3 5 JMP ->3 7 6 RETURN 1 7* ZEND_HANDLE_EXCEPTION	line # op fetch ext return operands ------------------------------------------------------------------------------- 2 0 ASSIGN $i, 0 3 1 IS_SMALLER ~1 $i, 1000 2 JMPZ ~1, ->5 4 3 PRE_INC !0 5 4 JMP ->1 9 5 RETURN 1 6* ZEND_HANDLE_EXCEPTION

Вывод: хотя цикл while выглядит многословнее (по крайней мере, длиннее), он, на удивление, оказывается короче полностью аналогичного цикла for. Таким образом, не всегда более короткий код оказывается более эффективным. При этом так как второй вариант короче (в плане количества опкодов), он потребляет меньше памяти.

Пустая строка или `NULL`?

	Пустая строка	`null`
Код	$a = ""; echo memory_get_usage(); ?>	$a = NULL; echo memory_get_usage(); ?>
Результат	106,336	106,224

Вывод: использование пустых значений «сложных» типов (строки, массивы, объекты) ведёт к повышенному потреблению памяти. Использование NULL — самый оптимальный вариант.

`is_null()` или строгая проверка на `NULL`?

	`is_null`	Строгое соответствие
Код	$a = 0; if (is_null($a)) { } ?>	$a = 0; if ($a === NULL) { } ?>
Результат	line # op fetch ext return operands ------------------------------------------------------------------------------- 2 0 ASSIGN $a, 0 3 1 SEND_VAR $a 2 DO_FCALL 1 'is_null' 3 JMPZ $1, ->5 4 4 JMP ->5 6 5 RETURN 1 6* ZEND_HANDLE_EXCEPTION	line # op fetch ext return operands ------------------------------------------------------------------------------- 2 0 ASSIGN $a, 0 3 1 IS_IDENTICAL ~1 $a, null 2 JMPZ ~1, ->4 4 3 JMP ->4 6 4 RETURN 1 5* ZEND_HANDLE_EXCEPTION

Вывод: проверка на строгое равенство NULL работает быстрее, в том числе из-за отсутствия необходимости вызова функции.

`echo`: конкатенация или запятые?

	Конкатенация	Запятые
Код	echo 'Memory ' . 'usage ' . 'is ' . memory_get_usage() . "\n"; ?>	echo 'Memory ', 'usage ', 'is ', memory_get_usage(), "\n"; ?>
Результат	line # op fetch ext return operands ------------------------------------------------------------------------------- 2 0 CONCAT ~0 'Memory ', 'usage ' 1 CONCAT ~1 ~0, 'is ' 2 DO_FCALL 0 'memory_get_usage' 3 CONCAT ~3 ~1, $2 4 CONCAT ~4 ~3, '\n' 5 ECHO ~4 3 6 RETURN 1 7* ZEND_HANDLE_EXCEPTION	line # op fetch ext return operands ------------------------------------------------------------------------------- 2 0 ECHO 'Memory ' 1 ECHO 'usage ' 2 ECHO 'is ' 3 DO_FCALL 0 'memory_get_usage' 4 ECHO $0 5 ECHO '\n' 3 6 RETURN 1 7* ZEND_HANDLE_EXCEPTION
	Memory usage is 106192	Memory usage is 106184

Выводы: в очередной раз менее читабельный метод оказался лучшим — на этот раз в плане потребления памяти. И, как видим, PHP не догадался даже объединить строки вместе.

Что быстрее: статический или динамический метод?

	Динамический метод	Статический метод
Код	class A { public function test() {} } $a = new A; $a->test(); ?>	class A { public static function test() {} } $a = new A; A::test(); ?>
Результат	line # op fetch ext return operands ------------------------------------------------------------------------------- 2 0 NOP 6 1 ZEND_FETCH_CLASS :1 'A' 2 NEW $2 :1 3 DO_FCALL_BY_NAME 0 4 ASSIGN $a, $2 7 5 ZEND_INIT_METHOD_CALL $5 $a, 'test' 6 DO_FCALL_BY_NAME 0 8 7 RETURN 1 8* ZEND_HANDLE_EXCEPTION	line # op fetch ext return operands ------------------------------------------------------------------------------- 2 0 NOP 6 1 ZEND_FETCH_CLASS :1 'A' 2 NEW $2 :1 3 DO_FCALL_BY_NAME 0 4 ASSIGN $a, $2 7 5 ZEND_FETCH_CLASS :5 'A' 6 ZEND_INIT_STATIC_METHOD_CALL null, 'test' 7 DO_FCALL_BY_NAME 0 8 8 RETURN 1 9* ZEND_HANDLE_EXCEPTION

Выводы: при прочих равных условиях, вызов статического метода на один опкод длиннее вызова динамического метода. Таким образом, если делать все методы класса, которые не используют $this, статическими, это приведёт к потреблению памяти.

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

PHP: красота кода сказывается на производительности

Vladimir — Fri, 25 Sep 2009 01:14:52 +0000

Читабельный код выполняется медленнее

Недавно я для себя открыл, что PHP не умеет оптимизировать код, а тут новый удар: оказывается, что красота кода отрицательно влияет на производительность.

Как и в прошлый раз, для проверки гипотез использовался Vulcan Logic Disassembler.

Сравнивались два куска кода:

Тест №1:

$a = true;
if (true == $a) {
print 1;
}
?>

и абсолютно аналогичный по функциональности

Тест №2:

$a = true;
if ($a) {
print 1;
}
?>

На выходе получилась такая картина.
Для первого случая:

line # op fetch ext return operands
-------------------------------------------------------------------------------
2 0 FETCH_CONSTANT ~0 'true'
1 ASSIGN $a, ~0
3 2 FETCH_CONSTANT ~2 'true'
3 IS_EQUAL ~3 ~2, $a
4 JMPZ ~3, ->8
4 5 PRINT ~4 1
6 FREE ~4
5 7 JMP ->8
6 8 RETURN 1
9* ZEND_HANDLE_EXCEPTION

Для второго случая:

line # op fetch ext return operands
-------------------------------------------------------------------------------
2 0 FETCH_CONSTANT ~0 'true'
1 ASSIGN $a, ~0
3 2 JMPZ $a, ->6
4 3 PRINT ~2 1
4 FREE ~2
5 5 JMP ->6
6 6 RETURN 1
7* ZEND_HANDLE_EXCEPTION

Видим, что в первом случае PHP, как мы его и попросили, честно сравнил true c $a и проверил, равен ли результат сравнения нулю или нет. Во втором же случае PHP просто проверил, равно ли $a нулю, сэкономив два опкода.

Будучи любопытным, я заменил проверку на равенство true проверкой на неравенство false. Хрен редьки не слаще: те же 9 опкодов:

line # op fetch ext return operands
-------------------------------------------------------------------------------
2 0 FETCH_CONSTANT ~0 'true'
1 ASSIGN $a, ~0
3 2 FETCH_CONSTANT ~2 'false'
3 IS_NOT_EQUAL ~3 ~2, $a
4 JMPZ ~3, ->8
4 5 PRINT ~4 1
6 FREE ~4
5 7 JMP ->8
6 8 RETURN 1
9* ZEND_HANDLE_EXCEPTION

Попутно выяснил, что те, кто говорят, что echo быстрее, чем print, правы. Я поменял print 1; на echo 1, в результате код программы сократился на один опкод:

line # op fetch ext return operands
-------------------------------------------------------------------------------
2 0 FETCH_CONSTANT ~0 'true'
1 ASSIGN $a, ~0
3 2 FETCH_CONSTANT ~2 'false'
3 IS_NOT_EQUAL ~3 ~2, $a
4 JMPZ ~3, ->7
4 5 ECHO 1
5 6 JMP ->7
6 7 RETURN 1
8* ZEND_HANDLE_EXCEPTION

Затем я решил проверить, что лучше: switch или спагетти из if/elseif.

Тест №3

$a = 5;
if ($a == 1) {
echo 1;
}
elseif ($a == 2) {
echo 2;
}
elseif ($a == 3) {
echo 3;
}
else {
echo ":-(";
}
?>

Результат:

line # op fetch ext return operands
-------------------------------------------------------------------------------
2 0 ASSIGN $a, 5
3 1 IS_EQUAL ~1 $a, 1
2 JMPZ ~1, ->5
4 3 ECHO 1
5 4 JMP ->14
6 5 IS_EQUAL ~2 $a, 2
6 JMPZ ~2, ->9
7 7 ECHO 2
8 8 JMP ->14
9 9 IS_EQUAL ~3 $a, 3
10 JMPZ ~3, ->13
10 11 ECHO 3
11 12 JMP ->14
13 13 ECHO ':-('
15 14 RETURN 1
15* ZEND_HANDLE_EXCEPTION

Тест №4

$a = 5;
switch ($a) {
case 1:
echo 1;
break;
case 2:
echo 2;
break;
case 3:
echo 3;
break;
default:
echo ":-(";
break;
}
?>

Результат:

line # op fetch ext return operands
-------------------------------------------------------------------------------
2 0 ASSIGN $a, 5
4 1 CASE ~1 $a, 1
2 JMPZ ~1, ->6
5 3 ECHO 1
6 4 BRK 1
7 5* JMP ->8
6 CASE ~1 $a, 2
7 JMPZ ~1, ->11
8 8 ECHO 2
9 9 BRK 1
10 10* JMP ->13
11 CASE ~1 $a, 3
12 JMPZ ~1, ->16
11 13 ECHO 3
12 14 BRK 1
13 15* JMP ->17
16 JMP ->20
14 17 ECHO ':-('
15 18 BRK 1
16 19* JMP ->21
20 JMP ->17
17 21 RETURN 1
22* ZEND_HANDLE_EXCEPTION

Результат для switch хоть и более читаемый, но оказался в полтора раза хуже результата для if. Sad but true.

После этого я собрал (с поддержкой оптимизатора) и поставил eAccelerator и повторил тесты.

Тест №1 и тест №2 дали одинаковый результат:

line # op fetch ext return operands
-------------------------------------------------------------------------------
2 0 ASSIGN $a, true
3 1 JMPZ $a, ->3
4 2 ECHO 1
6 3 RETURN 1
4* ZEND_HANDLE_EXCEPTION

Что характерно, eAccelerator самостоятельно преобразовал print в echo. Лапочка.

Для теста №3 результат остался неизменным: там, собственно, нечего оптимизировать.

А результаты теста №4 впечатлили:

2 0 ASSIGN $a, 5
4 1 CASE ~0 $a, 1
2 JMPZ ~0, ->5
5 3 ECHO 1
17 4 RETURN 1
7 5 CASE ~0 $a, 2
6 JMPZ ~0, ->9
8 7 ECHO 2
17 8 RETURN 1
10 9 CASE ~0 $a, 3
10 JMPZ ~0, ->13
11 11 ECHO 3
17 12 RETURN 1
14 13 ECHO ':-('
17 14 RETURN 1
15* ZEND_HANDLE_EXCEPTION

На выходе получили результат, который по эффективности аналогичен коду из if!

Поэтому в заключение скажу: ставьте eAccelerator и будет всем счастье!

SJ Hook Profiler — плагин для измерения производительности хуков

Vladimir — Mon, 21 Sep 2009 23:01:11 +0000

Поиск слабых мест в WordPress и bbPress

Сразу оговорюсь, что речь пойдёт совсем не о боксе, а о WordPress и bbPress.

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

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

В отличие от WP Tuner, которому явно нужно указывать, какие события нужно профилировать, SJ Hook Profiler автоматически определяет все используемые хуки и устанавливает обработчики, измеряющие их время работы. На выходе получается что-то вида данной таблицы:

Hook Name	Total Time	Invocations	Average Time
pre_option_gmt_offset	0.000169	1	0.000169
option_blog_charset	0.000405	11	0.000037
plugins_loaded	0.014295	1	0.014295
option_siteurl	0.000810	26	0.000031
option_home	0.004852	160	0.000030
sanitize_comment_cookies	0.000117	1	0.000117
option_category_base	0.000029	1	0.000029
option_tag_base	0.000027	1	0.000027
setup_theme	0.000030	1	0.000030
wp_default_scripts	0.001951	1	0.001951
set_current_user	0.000114	1	0.000114
init	0.011603	1	0.011603
widgets_init	0.003384	1	0.003384
wp_default_styles	0.000349	1	0.000349
query_vars	0.000036	1	0.000036
sanitize_title	0.001518	17	0.000089
posts_where	0.000033	1	0.000033
the_posts	0.000127	1	0.000127
template_redirect	0.000541	1	0.000541
bloginfo	0.002297	8	0.000287
term_name	0.000621	2	0.000310
term_description	0.000982	2	0.000491
single_post_title	0.000468	2	0.000234
wp_title	0.000747	2	0.000373
wp_head	0.020773	1	0.020773
comments_open	0.000373	4	0.000093
the_title	0.011747	46	0.000255
wp_print_styles	0.000175	2	0.000088
style_loader_src	0.000330	9	0.000037
wp_print_scripts	0.000440	1	0.000440
print_scripts_array	0.000050	1	0.000050
wp_list_pages	0.000305	1	0.000305
the_author	0.000534	2	0.000267
the_content	1.004469	1	1.004469
comment_text	0.001105	1	0.001105
pings_open	0.000087	1	0.000087
comment_form	0.007084	1	0.007084
widget_title	0.001137	4	0.000284
list_cats	0.004768	22	0.000217
wp_footer	0.009798	1	0.009798
wp_print_footer_scripts	0.000115	1	0.000115

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

Одна из особенностей плагина — поддержка как WordPress, так и bbPress (правда, пришлось немного поколдовать).

По умолчанию плагин активен только для администратора (WordPress) и Key Master (bbPress); изменить это можно, повесив обработчик на фильтр enable_hook_profiler (должен вернуть true, если профайлер нужно активировать и false в противном случае).

Скачать плагин SJ Hook Profiler 0.1.
Скачать плагин SJ Hook Profiler 0.2.