Смешно медленные SQL-запросы на Heroku

Question

Я запускаю приложение Rails 3 на Heroku и использую NewRelic для контроля производительности. Каждые несколько часов я вижу отчеты ОЧЕНЬ медленных запросов, которые не имеют для меня никакого смысла.

Например, у меня есть таблица событий, в которой есть столбцы года, месяца и дня (думая об этом сейчас, это, вероятно, не самый эффективный дизайн, но независимо от того, я не думаю, что это должно сильно замедлить запросы). Эта таблица индексируется по 4 столбцам, (user_id, год, месяц, день - упорядочено по дням).

NewRelic показывает, что база данных занимает 3,2 секунд для запуска следующего запроса. Я понятия не имею, почему, потому что у всей таблицы всего около 6 тыс. Строк, а все мое приложение обслуживает в среднем 5,67 запросов в минуту.

Есть ли что-то, что мне не хватает здесь? Возможно, это потому, что я нахожусь только на одном веб-диноде, и этот динот будет спать? Если это так, почему NewRelic сообщит о нем как о медленном SQL-запросе?

SELECT `events`.* FROM `events` WHERE `events`.`user_id` = 5308 AND `events`.`year` = 2014 AND `events`.`month` = 1 ORDER BY day ASC 

Вот SQL EXPLAIN по запросу:

Query plan Sort (cost=20.50..20.50 rows=11 width=89) 
Query plan Sort Key: day 
Query plan -> Bitmap Heap Scan on events (cost=2.08..20.46 rows=11 width=89) 
Query plan Recheck Cond: ((user_id = 5308) AND (year = 2014) AND (month = 1)) 
Query plan -> Bitmap Index Scan on index_events_on_user_id_and_year_and_month_and_day (cost=0.00..2.08 rows=11 width=0) 
Query plan Index Cond: ((user_id = 5308) AND (year = 2014) AND (month = 1)) 

Answer 1

Что нового Relic сообщает не только время, необходимое для выполнения запроса на сервере базы данных. Сообщалось о более широком измерении. Он включает время, затрачиваемое на подготовку запроса через ActiveRecord, отправку запроса по проводке на сервер базы данных, выполнение запроса, получение ответа по проводу с сервера базы данных и анализ ответа обратно на набор объектов Ruby в ActiveRecord.

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