SQLMon для Code Igniter

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

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

[-]
View Code PHP
$this->output->enable_profiler(TRUE);

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

Автор: Vladimir, опубликовано в: PHP, комментариев: нет
13
Фев
2010

SQLMon для Kohana 3

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

для интегрируется в иерархию классов Database (встраивается между классами Database_ и Kohana_Database_) и реализует обёртку над методом Kohana_Database_MySQL::query(), измеряя время выполнения запроса, объём потребляемой памяти, записывая код ошибки запроса, трассу вызовов и EXPLAIN запроса (причём не только для SELECT, но и UPDATE/DELETE и INSERT/REPLACE INTOAS или CREATE  TABLEAS) — всё то же самое, что и SQLMon для WordPress. Далее »

Автор: Vladimir, опубликовано в: Kohana, комментариев: 2
9
Фев
2010

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

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

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

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

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

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

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

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

Внимание:

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

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

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

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

Ужасы таксономии в WordPress

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

Я взял свежую дефолтную инсталляцию  2.8-bleeding, сгенерировал тестовый контент и пошел искать недоработки и проблемы с производительностью. Одну из них я нашел очень быстро: при попытке удалить категорию, в которой была 1,001 ночь запись.

На неслабом сервере это заняло около 20 секунд и… более 12,000 запросов (да-да, двенадцати тысяч, я количеством ноликов, увы, не ошибся). Далее »

Автор: Vladimir, опубликовано в: WordPress, комментариев: 14
9
Июнь
2009

Увеличение производительности плагина NextGen Gallery

В случае, если галереи содержат несколько тысяч изображений, в зависимости от мощности сервера и посещаемости сайта могут возникнуть проблемы с производительностью, связанные с неоптимальностью индексов в таблице wp_ngg_pictures. Далее »

Автор: Vladimir, опубликовано в: WordPress, комментариев: 2
6
Июнь
2009