Ars Longa, Vita Brevis » SQLMon

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 — скачать бесплатно без регистрации без смс

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

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.

SQLMon: плагин для анализа SQL-запросов

Vladimir — Fri, 13 Jun 2008 00:17:34 +0000

Поиск слабых мест производительности: анализируем SQL-запросы

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

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

Однажды столкнувшись с ужасной производительностью WordPress и не имея возможности анализировать код десятка поставленных плагинов, я стал решать задачу иначе, в результате чего родился плагин для анализа SQL-запросов.

Принцип работы. Плагин устанавливает обработчики действий, которые позволяют перехватить запрос к базе данных непосредственно перед его выполнением. Если перехваченный запрос — SELECT, UPDATE или DELETE, то скрипт пытается его «объяснить» — выполнить EXPLAIN над запросом. Предвидя возражения, что EXPLAIN работает только с SELECT, но никак не с DELETE и UPDATE, поясняю: запросы DELETE и UPDATE переписываются в SELECT, например:

DELETE `t1`
FROM `t1`
INNER JOIN `t2`
ON `t1`.`id` = `t2`.`id`
WHERE `t2`.`key` = 'value'
LIMIT 5

будет переписан в

EXPLAIN SELECT *
FROM `t1`
INNER JOIN `t2`
ON `t1`.`id` = `t2`.`id`
WHERE `t2`.`key` = 'value'
LIMIT 5

Возможно, переписывание работает не всегда, но такие случаи мне еще не встречались

Я предполагаю, что Вы понимаете, для чего нужен EXPLAIN и как следует понимать результаты, которые он выдаёт. Если это не так, то очень рекомендую прочитать статью «Optimizing Queries with EXPLAIN», а затем вернуться к данной статье.

Плагин в футере темы (кстати, это относится и к админке) выдаст подробный лог запросов с их объяснением. Это может выглядеть примерно так:

Скачать SqlMon.

Установка. К сожалению, установка данного плагина полностью не автоматизируется: кое-что надо делать вручную. После активации плагина в WordPress нужно выполнить следующие действия:

Добавить в файл /wp-config.php следующие строки:

define('SQLMON_ENABLED', true);
$sqlmon_allowed_ips = array('70.87.222.86', '195.10.218.132', '127.0.0.1');

Первая строка активирует режим перехвата и анализа запросов, вторая строка содержит массив с IP-адресами, которым разрешен просмотр лога запросов. Естественно, нужно указать свои адреса
Далее предстоит пропатчить один файлик WordPress: /wp-includes/wp-db.php. Сразу объясню, зачем это нужно: WordPress не предоставляет нормальных возможностей отловить запрос до его выполнения. Фильтр query для наших целей не подходит: во-первых, последующий плагин может переписать запрос, во-вторых, я уже насмотрелся на плагины, которые лезут переписывать запрос, если видят SELECT. Проверено, что переписывание EXPLAIN SELECT такими плагинами приводит к синтаксической ошибке.
Теперь о том, что нужно менять. В файле /wp-includes/wp-db.php есть класс wpdb, в котором есть метод query. В этом методе нужно найти строки

// Perform the query via std mysql_query function..
if (SAVEQUERIES)
$this->timer_start();

$this->result = @mysql_query($query, $this->dbh);

++$this->num_queries;

и изменить их:

// Perform the query via std mysql_query function..
if (SAVEQUERIES)
$this->timer_start();

if (true == function_exists('do_action')) {
do_action('before_query', $query, $this->dbh);
}

$this->result = @mysql_query($query, $this->dbh);

if (true == function_exists('do_action')) {
do_action('after_query', $query, $this->dbh);
}

++$this->num_queries;

Для тех, кто предпочитает иметь дело с патчами, привожу патч в формате unified diff (внимание: патч проверялся только на WordPress 2.5.1):

--- wp-db.old.php 2008-03-21 01:34:32.000000000 +0200
+++ wp-db.php 2008-06-13 03:02:27.000000000 +0300
@@ -272,7 +272,16 @@
if (SAVEQUERIES)
$this->timer_start();

+ if (true == function_exists('do_action')) {
+ do_action('before_query', $query, $this->dbh);
+ }
+
$this->result = @mysql_query($query, $this->dbh);
+
+ if (true == function_exists('do_action')) {
+ do_action('after_query', $query, $this->dbh);
+ }
+
++$this->num_queries;

if (SAVEQUERIES)

После этого перезагружаем страницу и смотрим

Update: для WordPress 2.6 патч будет выглядеть следующим образом:

--- wp-db.old.php 2008-07-11 04:49:06.000000000 +0300
+++ wp-db.php 2008-08-03 10:39:14.000000000 +0300
@@ -605,7 +605,16 @@
if ( defined('SAVEQUERIES') && SAVEQUERIES )
$this->timer_start();

+ if (true == function_exists('do_action')) {
+ do_action('before_query', $query, $this->dbh);
+ }
+
$this->result = @mysql_query($query, $this->dbh);
+
+ if (true == function_exists('do_action')) {
+ do_action('after_query', $query, $this->dbh);
+ }
+
++$this->num_queries;

if ( defined('SAVEQUERIES') && SAVEQUERIES )

Данная версия плагина больше не поддерживается, так как есть новая версия плагина SQLMon, которая, к тому же, не требует внесения изменений в код WordPress.