SQLMon для Yii
Одной из вещей, которых мне очень не хватало при разработке сайтов на Yii — нормального отображения всех запросов к базе данных, что дало бы возможность их последующего анализа.
Ситуацию частично исправило расширение под названием Yii DB profiler. Но остались некоторые неудобства:
- Отображение запросов в порядке убывания времени выполнения — в принципе, это дело вкуса: при таком порядке сразу видны проблемные запросы. С другой стороны, лично мне более привычен хронологический порядок — так чётче прослеживается логика работы;
- Prepared statements. Это просто здорово, но если повторять запрос в phpMyAdmin (например, если интересует план выполнения запроса), бывает очень муторно заменять все связанные значения. Например, для запросов вида
[-]View Code MySQLзаменять все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.
Далее »
Ноя
2011
KSES в WordPress: можно ли проще?
Вчера мне довелось разбираться с тем, как работает KSES в WordPress.
KSES (рекурсивный акроним от KSES Strips Evil Scripts) — подсистема в WordPress (изначально написанная Ulf Harnhammar), предназначенная для проверки и очистки текста, введённого пользователем: она позволяет задать список допустимых тэгов, стилей и протоколов и на основе этих параметров убрать из текста пользователя всё, что им не соответствует.
KSES является довольно стабильной подсистемой; что немаловажно, KSES работает. Работает — не трогай, а то сломаешь… Далее »
Автор: Vladimir, опубликовано в: WordPress, комментариев: 23Фев
2011
Блокировки транзакций InnoDB при удалении данных из таблицы
Ситуация: есть несколько физических почтовых серверов (PowerMTA), отсылающих более четырёх миллионов сообщений в сутки. Есть виртуальный сервер базы данных (причём не очень мощный), на котором крутится MySQL с InnoDB; в базу данных пишутся логи доставки/не доставки сообщений и ведётся статистика по IP-адресам, VMTA и доменам. Попутно выполняется классификация и анализ hard и soft bounces. База за день увеличивается примерно на 5 гигабайт. Часть логов недельной давности удаляется. Далее »
Автор: Vladimir, опубликовано в: MySQL, комментариев: 2Фев
2011
WordPress: кэширование средствами nginx
Много было сказано про кэширование в WordPress… Сегодня я хочу рассказать о действительно эффективном методе, позволяющем сильно снизить нагрузку.
Метод основан на использовании кэша FastCGI web-сервера nginx.
Идея состоит в генерации статических страниц и отдачи их пользователям, не имеющим cookie комментатора. Зарегистрированным пользователям, а также комментаторам всегда отдаётся свежая страница. Так как читателей, ни разу не оставлявших комментарий, как правило, гораздо больше, чем комментаторов, то подобный использование кэша позволяет значительно снизить нагрузку на WordPress/PHP. Знакомые с принципом работы WP Super Cache заметят, что WPSC использует тот же принцип работы. Далее »
Автор: Vladimir, опубликовано в: nginx, WordPress, комментариев: 61Дек
2010
WP Super Cache vs MaxSite Cache: часть 2
Вторая часть статьи WP Super Cache vs MaxSite Cache.
В предыдущей части я сравнивал поведение MaxSite Cache и WP Super Cache на тестовом VDS (512 MiB RAM, 10 GB HD, Intel Xeon X3320 (1 ядро), 2.5 GHz), на котором ни операционная система, ни программное обеспечение не были специально настроены — бралась конфигурация «из коробки» и тестировалась. Одним словом, «VDS абсолютного чайника».
В этой части изменилась только конфигурация программного обеспечения: сервер настраивался на максимальную производительность.
В частности:
- отказ от Apache в пользу nginx и от
mod_php5в пользуphp-fcgi(количество FastCGI-процессов выбиралось таким образом, чтобы избежать использования файла подкачки); - смена ядра с
linux-image-serverнаlinux-image-virtual; - настройка MySQL: отказ от InnoDB (экономит примерно 100 МБ памяти), увеличение буфера ключей и т.п.;
- установка и настройка xCache (я исходил из того, что далеко не все чувствуют себя комфортно при сборке программ из исходников, поэтому брал только готовое ПО);
- настройка
iptablesдля фильтрации пакетов.
Дек
2009
Оптимизация All in One SEO Pack
Как оказалось, плагин 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) и получаем большую цифру. Далее »
Ноя
2009
WP Super Cache vs HyperCache vs W3 Total Cache vs MaxSite Cache
Для WordPress написано много кэширующих плагинов, предназначенных для борьбы со слабой производительностью сервера (либо кривыми руками администратора, который не в состоянии настроить PHP/MySQL). Простой пользователь зачастую задаётся вопросом: какой же из плагинов выбрать?
В данной статье я рассмотрю наиболее популярные плагины (WP Super Cache, Hyper Cache, W3 Total Cache и MaxSite Cache), а затем расскажу о результатах жестокого теста, которому я подверг все эти плагины. Далее »
Автор: Vladimir, опубликовано в: WordPress, комментариев: 53Ноя
2009
PHP: красота кода сказывается на производительности: часть 2
ifбыстрее, чемswitch;echoбыстрее, чемprint;- явная проверка на (не)нулевое значение медленнее, чем неявная.
- константные выражения, которые могут быть вычислены на этапе компиляции, не вычисляются;
- PHP не умеет удалять неиспользуемый код на этапе компиляции.
Продолжим. Далее »
Автор: Vladimir, опубликовано в: PHP, комментариев: 4Окт
2009
PHP: красота кода сказывается на производительности
Недавно я для себя открыл, что PHP не умеет оптимизировать код, а тут новый удар: оказывается, что красота кода отрицательно влияет на производительность. Далее »
Автор: Vladimir, опубликовано в: PHP, комментариев: 11Сен
2009
SJ Hook Profiler — плагин для измерения производительности хуков
Сразу оговорюсь, что речь пойдёт совсем не о боксе, а о WordPress и bbPress.
Разработчики плагинов WordPress и bbPress используют две функции для расширения функциональности WordPress/bbPress: это add_action() и add_filter(). Первая служит для установки обработчика некоторого события, вторая — для установки фильтра. Под хуком подразумевается обобщённое понятие (либо фильтр, либо обработчик).
Как показывает практика, большая часть времени генерации страницы уходит именно на вызов обработчиков и фильтров. И когда возникает вопрос: почему время генерации страницы такое большое, а запроса всего три, и они выполняются за сотые доли секунды, на помощь приходит данный плагин. Далее »
Автор: Vladimir, опубликовано в: bbPress, Плагины WordPress, комментариев: 3Сен
2009


Меня зовут Владимир, я программист-фрилансер, специализирующийся на Web-программировании и програмировании под Linux.
По совместительству занимаюсь администрированием LAMP/LNMP-серверов и техническим переводом.

