Обнаружение медленных SQL-запросов

Представляем вам Slow Query Notifier для Laravel. Если пакет обнаружит медленный запрос в вашем приложении, то вы получите уведомление.

Вдохновение

Мы сделали этот пакет после твита Marcel Pociot, который напомнил нам, что даже ДЕЙСТВИТЕЛЬНО ХОРОШИЕ разработчики иногда пишут медленные запросы:

Чтобы быть точным, этот запрос был нормальный (достаточно быстрый), пока в таблице не стало 40 миллионов записей. Тогда он начал становиться все медленнее и медленнее, увеличивая затраты. Наш пакет уведомит вас, как только вы зайдете на эту опасную территорию. Мы надеемся, что принесем в вашу жизнь больше покоя!

Установка

composer require thomasjohnkane/slow-query-notifier

Настройка email

// app/Providers/AppServiceProvider.php

use SlowQueryNotifier\SlowQueryNotifierFacade as SlowQueryNotifier;

public function boot()
{
  SlowQueryNotifier::toEmail('admin@example.com');
}

Проверка работы (в продакшене)

Если вы используете это в продакшене (как и предполагается), убедитесь, что оно работает правильно:

php artisan sqn:test

Эта команда проверит две вещи:

• Мы можем обнаружить медленные запросы в вашем приложении
• Мы можем отправить вам электронное письмо, если выполняется медленный запрос

Конфигурация

По дефолту всё настроено оптимально. Однако вы можете, разумеется, все изменить:

Threshold (Порог срабатывания)

По дефолту — 99 мс. Вы можете установить другой порог:

SlowQueryNotifier::threshold(200)->toEmail('admin@example.com');

Включение/отключение

Пакет по умолчанию включен. Установите в .env это значение в false, чтобы пропустить Слушателя.

SLOW_QUERY_NOTIFIER_ENABLED=false

Почему, в качестве Порога, мы выбрали 99мс

Многие эксперты в области оптимизации баз данных/запросов предлагают смотреть всё, что выполняется более 50 мс. Тем не менее, мы решили установить дефолтным значение 99 мс — вы получите уведомление, если запрос будет длиться вдвое больше, чем 50 мс. Но это не значит, что запрос в 100 мс — это плохо. Некоторые приложения и ситуации требуют, чтобы запросы выполнялись долго. В зависимости от ожиданий конкретных пользователей, 100мс запросы можно считать действительно быстрыми. Так что, вы можете установить этот значение по своему усмотрению. В будущем мы хотели бы иметь возможность устанавливать пороговые значения для «подключения». Тогда, в теории, у вас могло бы быть длительное подключение, которое не разорвёт ваш почтовый ящик.

Производительность

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

Без пакета:

Мы запустили запрос, который извлекает всех пользователей из базы данных. Маршрут с 1000 запросов (100 одновременных):

Нет существенной разницы в requests per second или time per request по сравнению с установленным пакетом.

С пакетом:

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

Планы и Следующие этапы

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

• 3 самых медленных запроса
• Полное сканирование таблицы и ситуаций «n+1»
• Любые запросы, которые превышают порог

Как альтернатива, мы хотели бы в конечном итоге брать эти данные из базы, а не из приложения. Например, похоже, что MySQL и Postgres позволяют мониторить производительность из коробки. Было бы неплохо просто создать графический интерфейс для отображения этих данных. Может быть через Nova?

Автор: Thomas Kane
Перевод: Алексей Широков