Ars Longa, Vita Brevis » оптимизация

Блокировки транзакций 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

Wandering Soul — Thu, 02 Sep 2010 17:48:38 +0000

Снижение пикового потребления памяти благодаря в два раза заменой одной функции

Пиковое потребление оперативной памяти WordPress можно снизить приблизительно два раза и практически бесплатно. В чём секрет? В использовании правильных функций для работы с базой данных.

Опытные программисты знают, что API MySQL предоставляет два варианта работы с результатом запроса:

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

Первому варианту соответствует использование функции PHP mysql_unbuffered_query(), второму — mysql_query().

WordPress использует именно второй вариант. Но специфика функции wpdb::query() такова, что, выполнив запрос, WordPress полностью читает ответ в переменную wpdb::last_result.

Таким образом, при выполнении запроса, возвращающего большой объём данных:

MySQL выделит память для временного буфера под весь результат запроса
WordPress создаст локальную копию результата запроса
После вызова mysql_result_free() временный буфер будет освобождён

В результате связка WordPress + MySQL съест в два раза больше памяти, чем нужно. Это особенно ощутимо на системах с небольшим количеством доступной оперативной памяти.

Лечение: в файле wp-includes/wp-db.php заменяем mysql_query на mysql_unbuffered_query.

Из бонусов: при использовании mysql_unbuffered_query() PHP будет получать данные по мере их доступности (во время выполнения запроса), в то время как при использовании mysql_query() пришлось бы ждать окончания выполнения запроса.

Использование небуферизованных запросов, судя по отзывам, очень сильно позволяет повысить производительность.

SQLMon для Code Igniter

Vladimir — Sat, 13 Feb 2010 06:10:58 +0000

Мониторинг SQL-запросов в Code Igniter

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

Этот минимум в Code Igniter достигается очень просто: вызовом

$this->output->enable_profiler(TRUE);

в контроллере. Но когда запросов на странице очень много, хотелось бы избавиться от рутинного выполнения EXPLAIN для каждого подозрительного запроса. Что, собственно, и делает SQLMon. Возникает логичное желание интегрировать его в Code Igniter.

Но в отличие от Kohana, с Code Igniter здесь не всё так просто. Во-первых, Code Igniter не поддерживает так называемую каскадную файловую систему. Во-вторых, Code Igniter не позволяет расширять или заменять класс Database. А изменять код системы (и поддерживать его при каждом обновлении) очень не хочется. Тем не менее, я нашел простое решение и реализовал соответствующую библиотеку.

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

Использование библиотеки. Библиотека состоит из двух частей:

Драйвер базы данных (каталог system/database/drivers/mysql_exp). Драйвер требует наличия драйвера MySQL (класс CI_DB_mysql_driver), так как, по сути дела, является производным от него классом. Драйвер переопределяет метод _execute(), в котором и выполняет анализ запроса.
Представление (view). Находится в каталоге system/application/views/sqlmon, используется для отображения результатов.

Установка библиотеки простая: содержимое каталога system/database должен быть скопировано в system/database, содержимое каталога system/application должно быть скопировано в каталог приложения. Затем нужно отредактировать настройки соединения с базой данных (файл appliaction/config/database.php): параметр dbdriver соединения нужно установить в mysql_exp.

Пример:

$active_group = "default";
$active_record = TRUE;

$db['default']['hostname'] = "localhost";
$db['default']['username'] = "username";
$db['default']['password'] = "password";
$db['default']['database'] = "database";
$db['default']['dbdriver'] = "mysql_exp"; // <<< Вот оно
$db['default']['dbprefix'] = "mso_";
$db['default']['pconnect'] = TRUE;
$db['default']['db_debug'] = TRUE;
$db['default']['cache_on'] = FALSE;
$db['default']['cachedir'] = "system/cache/db";
$db['default']['char_set'] = "utf8";
$db['default']['dbcollat'] = "utf8_general_ci";

Затем в соответствующее представление добавляем код:

$ci = &get_instance();
$ci->load->view('sqlmon/sqlmon');
?>

И наслаждаемся. На выходе должно получиться что-то вида (на примере MaxSite CMS; изображение можно кликнуть):

Скачать SQLMon для Code Igniter.

SQLMon для Kohana 3

Vladimir — Tue, 09 Feb 2010 19:16:01 +0000

Мониторинг SQL-запросов в Kohana 3

Продолжая славную традицию реализации SQLMon под различные CMS/фреймворки, написал одному заказчику модуль для Kohana 3.

SQLMon для Kohana 3 интегрируется в иерархию классов Database (встраивается между классами Database_MySQL и Kohana_Database_MySQL) и реализует обёртку над методом Kohana_Database_MySQL::query(), измеряя время выполнения запроса, объём потребляемой памяти, записывая код ошибки запроса, трассу вызовов и EXPLAIN запроса (причём не только для SELECT, но и UPDATE/DELETE и INSERT/REPLACE INTO … AS или CREATE TABLE … AS) — всё то же самое, что и SQLMon для WordPress.

Данный модуль будет полезен разработчикам для анализа производительности запросов MySQL и поиска решений для их оптимизации. Перед использованием модуля рекомендуется прочитать статью «Optimizing Queries with EXPLAIN».

Использование модуля. Модуль должен быть распакован в каталог modules проекта (после распаковки появится каталог sqlmon). Затем модуль должен быть активирован в файле application/bootstrap.php. Очень важно, чтобы модуль подключался перед модулем database — это связано с особенностями поиска классов в Kohana 3.

Например:

Kohana::modules(array(
'sqlmon' => MODPATH.'sqlmon', // SQL Monitor — обязательно перед Database
'database' => MODPATH.'database', // Database access
'orm' => MODPATH.'orm', // Object Relationship Mapping
'pagination' => MODPATH.'pagination', // Paging of results
));

Для отображения статистики нужно выполнить

echo View::factory('sqlmon/sqlmon'); ?>

Результатом будет нечто вида (скриншот можно кликнуть):

Настройка. SQLMon использует файлы конфигурации модуля Database — config/database.php. Для контроля поведения SQLMon нужно использовать параметры:

backtrace — boolean (по умолчанию true) — должен ли SQLMon отображать трассу вызовов (то, что отображается синим цветом на скриншоте выше);
explain — boolean (по умолчанию true) — должен ли SQLMon отображать план выполнения запросов (EXPLAIN).

Пример файла конфигурации:

return array(
'default' => array(
'type' => 'mysql',
'profiling' => true,
'charset' => 'utf8',
'table_prefix' => '',
// Настройки SQLMon
'backtrace' => true,
'explain' => true,
// ---
'connection' => array(
'username' => 'root',
'password' => 'M1dn19ht',
'hostname' => 'localhost',
'persistent' => false,
'database' => 'feedfetcher'
),
)
);
?>

Скачать SQLMon для Kohana 3.

Оптимизация изображений без потерь

Vladimir — Sat, 28 Nov 2009 19:18:49 +0000

Smush.IT™ на локальном компьютере

Внимание: в данной статье описывается скрипт оптимизации изображений для Linux. Если вы ищите программу для оптимизации изображений для Windows, то это PictureBeaver.

Один из советов по ускорению загрузки сайта, который даёт Yahoo! Exceptional Performance Team — это оптимизация изображений. Оптимизация без потерь (рассматриваться будет именно она) позволяет уменьшить размер изображений (временами очень даже значительно) и за счёт этого уменьшить общее время, требуемое для загрузки страницы.

Уменьшение размера изображения без потери качества достигается рядом способов:

использование другого алгоритма сжатия данных либо использование более агрессивных параметров (как правило, чем выше степень сжатия, тем больше времени уходит на сжатие);
удаление информационных блоков, наличие или отсутствие которых не влияет на декодирование изображения;
оптимизация цветов (например, если изображение сохранено в формате PNG32 — 4 байта на пиксель, но реально используются только 16 цветов — 4 бита на пиксель, то оптимизация цветов (color reduction) позволит значительно уменьшить размер файла).

Yahoo! предоставляет бесплатный сервис Yahoo! Smush.it™, который позволяет оптимизировать графику в онлайн-режиме, но его использование не всегда удобно. Гораздо удобнее, когда всё можно сделать на своём компьютере.

Нам понадобятся:

gifsicle для оптимизации GIF-изображений и анимаций;
optipng для оптимального сжатия PNG-файлов (что достигается путём перебора множества параметров, влияющих на работу алгоритма сжатия);
pngcrush для удаления лишних блоков из PNG-файла. Как и optipng, pngcrush умеет определять оптимальные параметры сжатия (optipng — это форк pngcrush), но, как показали тесты, у optipng это получается чуть лучше;
jpegtran позволяет выполнять преобразования без потерь над файлами JPEG (в частности, удаление лишних информационных блоков и перестраивание данных — коэффициентов дискретно-косинусного преобразования);
ImageMagick для определения формата изображений;
AdvanceCOMP позволяет достичь лучших результатов сжатия PNG-файлов, благодаря использованию реализации 7-Zip Defalte.

Весь этот зоопарк в дистрибутивах Linux, основанных на Debian, устанавливается так:

sudo apt-get install advancecomp gifsicle optipng libjpeg-progs imagemagick pngcrush

Затем загружаем этот скрипт:

#! /bin/sh

if [ -z "$1" ]; then
echo "Usage: optimize-image.sh filename"
exit 1;
fi

if [ ! -f "$1" ]; then
echo "$1 is not a file"
exit 1;
fi

TYPE=`identify "$1" | grep -E -o 'JPEG|GIF|PNG'`
OLD=`stat -c %s "$1"`

case "$TYPE" in
JPEG)
jpegtran -copy none -optimize -perfect -progressive -outfile "$1.tmp" "$1"
jpegtran -copy none -optimize -perfect -outfile "$1.tmq" "$1"
if [ -f "$1.tmp" -a -f "$1.tmq" ]; then
S_PROG=`stat -c %s "$1.tmp"`
S_NORM=`stat -c %s "$1.tmq"`
if [ $S_PROG -ge $S_NORM ]; then
mv -f "$1.tmq" "$1"
rm -f "$1.tmp"
else
mv -f "$1.tmp" "$1"
rm -f "$1.tmq"
fi;
fi
;;

GIF)
gifsicle -O2 -b "$1"
;;

PNG)
pngcrush -q -rem alla -fix "$1" "$1.tmp"
if [ -f "$1.tmp" ]; then
mv -f "$1.tmp" "$1"
fi;
optipng -zc6-9 -zm1-9 -zs0-3 -f0-5 -q -fix "$1"
advpng -z -4 -q "$1"
;;
esac

NEW=`stat -c %s "$1"`
echo "$1, old size: $OLD, new size: $NEW"

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

Для JPEG-файлов пробуется два разных способа кодирования: Progressive (низкочастотные коэффициенты находятся в начале файла) и обычное кодирование. В зависимости от изображение, Progressive JPEG может быть меньшим по размеру, чем non-progressive JPEG и наоборот.

Из PNG-файлов удаляются все лишние информационные блоки, после чего выполняется поиск оптимального варианта сжатия. Файл, сжатый optipng, обрабатывается advpng, который, в ряде случаев, позволяет достичь еще большего коэффициента сжатия.

GIF-файлы обрабатываются только gifsicle, я не добавлял код, который бы преобразовывал GIF в PNG и проверял, что лучше (так как в этом случае пришлось бы руками исправлять все ссылки на GIF-файл и заменять их ссылками на PNG).

Пример использования:

find -type f $ -name "*.png" -o -name "*.gif" -o -name "*.jpg" -o -name "*.JPG" $ -exec optimize-image.sh '{}' \;

Внимание, перед использованием скрипта не забываем о необходимости резервного копирования! Хотя скрипт и тестировался в боевых условиях, осторожность никто не отменял.

Еще одна оптимизация NextGen Gallery

Vladimir — Mon, 23 Nov 2009 21:19:54 +0000

Минус один UPDATE при каждом обращении к блогу

Плагин NextGen Gallery имеет одну неприятную особенность: при каждом обращении к блогу выполняется обновление (UPDATE в терминах MySQL) таблицы wp_options. Хотя для «средних» блогов это не критично, для хорошо посещаемых ресурсов это плохо по ряду причин:

Обновление таблицы wp_options сбрасывает кэш запросов MySQL к таблице wp_options, что приводит к необходимости реального выполнения запросов на выборку данных (с учётом огромного количества записей — благодаря всяким разным плагинам — это лишний трафик между PHP и MySQL).
Выполнение операции обновления таблицы при использовании MyISAM приводит к блокировке таблицы; при высокой посещаемости это приводит к вынужденному ожиданию освобождения таблицы и негативно сказывается на нагрузке и производительности.
При использовании плагинов объектного кэширования каждый вызов update_option() приводит к необходимости обновления и записи кэша; обновление файлового объектного кэша приводит к лишним обращениям к диску (которых на виртуальных серверах лучше избегать).
В конце концов, это лишний запрос, который не является необходимым.

Использование плагина MySQL Monitor показывает:

Запрос:

UPDATE `wp_options` SET `option_value` = 'a:3:{i:0;b:0;s:29:\"nextgen-gallery/nggallery.php\";a:2:{i:0;s:9:\"nggLoader\";i:1;s:9:\"uninstall\";}...}' WHERE `option_name` = 'uninstall_plugins'
Трасса вызовов:

wp-includes/wp-db.php, 830 (DbProfile::query)
wp-includes/functions.php, 533 (wpdb::update)
wp-includes/plugin.php, 608 (update_option)
wp-content/plugins/nextgen-gallery/nggallery.php, 80 (register_uninstall_hook)
wp-content/plugins/nextgen-gallery/nggallery.php, 429 (nggLoader::nggLoader)
wp-settings.php, 566 (include_once)
wp-config.php, 84 (require_once)
wp-load.php, 30 (require_once)
wp-blog-header.php, 12 (require_once)
index.php, 17 (require)

Говоря простым языком, NextGen Gallery при каждой загрузке WordPress регистрирует функцию деинсталляции плагина. Таким образом, если мы имеем 25,000 показов страниц в день, это выливается в 25,000 (относительно медленных) запросов UPDATE к базе.

Проблема решается очень просто: вызов функции register_uninstall_hook переносится из конструктора nggLoader::nggLoader() (файл nextgen-gallery/nggallery.php) в самый конец функции nggLoader::activate() (за строку delete_option( 'ngg_update_exists' );).

Получаем простой патч:

--- nggallery.php.old 2009-11-23 22:06:09.000000000 +0200
+++ nggallery.php 2009-11-23 22:07:55.000000000 +0200
@@ -76,9 +76,6 @@
register_activation_hook( $this->plugin_name, array(&$this, 'activate') );
register_deactivation_hook( $this->plugin_name, array(&$this, 'deactivate') );

- // Register a uninstall hook to remove all tables & option automatic
- register_uninstall_hook( $this->plugin_name, array('nggLoader', 'uninstall') );
-
// Start this plugin once all other plugins are fully loaded
add_action( 'plugins_loaded', array(&$this, 'start_plugin') );

@@ -376,6 +373,8 @@
// remove the update message
delete_option( 'ngg_update_exists' );

+ // Register a uninstall hook to remove all tables & option automatic
+ register_uninstall_hook( $this->plugin_name, array('nggLoader', 'uninstall') );
}

function deactivate() {

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.

Оптимизация байт-кода в PHP

Vladimir — Tue, 15 Sep 2009 19:02:59 +0000

Отсутствие всякой оптимизации кода в PHP

Я давно задавался вопросом, насколько «умным» является интерпретатор PHP в том, что касается оптимизации. В частности, меня всегда интересовала поддержка исключения неиспользуемого кода (известная как dead code elimination) и распространение константных значений (constant propagation). И теперь, когда я вплотную занялся изучением внутренностей Zend Engine, у меня такая возможность появилась.

Я взял простой тестовый файл:

$a = 2 * 2;
$a = 3 * 3;
print $a;
?>

В идеале выражения 2*2 и 3*3 должны вычисляться на этапе компиляции, выражение $a = 2 * 2; выбрасываться за ненужностью (ибо его вычисление не связано с побочными эффектами, а результат не используется), а print $a; заменяться print 9; (ибо значение $a известно).

Результирующий код «дизассемблировался» самопальным zend-расширением (которое пока за сыростью его исходников в общий доступ выкладывать не буду).
Результирующий код «дизассемблировался» при помощи замечательного расширения Vulcan Logic Disassembler, спасшего меня от изобретения очередного велосипеда.

На выходе получился такой результат:

line # op fetch ext return operands
-------------------------------------------------------------------------------
2 0 MUL ~0 2, 2
1 ASSIGN $a, ~0
3 2 MUL ~2 3, 3
3 ASSIGN $a, ~2
4 4 PRINT ~4 $a
5 FREE ~4
5 6 RETURN 1
7* ZEND_HANDLE_EXCEPTION

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

Поэтому когда китайские программисты наблюдают дао присваивания ($a = $a;), это вредит производительности.