Случайные медленные запросы на Heroku

Мы видим несогласованную производительность на Heroku, которая не связана с недавней проблемой единорога/интеллектуальной маршрутизации.

Это пример запроса, который обычно занимает ~ 150 мс (и 19 из 20 раз, сколько требуется). Вы можете видеть, что по этой просьбе потребовалось около 4 секунд, или от 1 до 2 порядков.

enter image description here

Некоторые примечания:

  • база данных не была узким местом, и она потратила всего 25 мс на выполнение запросов db
  • у нас более чем достаточно динозавров, поэтому я не думаю, что это было узким местом (20 двойных динозавров с единорогом с 5 рабочими каждый, мы получаем только 1000 запросов в минуту, среднее время отклика 150 мс, что означает, что мы должны быть (60/0.150) * 20 * 5 = 40 000 запросов в минуту. Другими словами, когда это измерение было выполнено, у нас была 40-кратная емкость на динамиках.

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

Ответы

Ответ 1

Я сам преследовал аналогичную проблему, пока не очень повезло.

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

Во-вторых, я предлагаю вам посмотреть время в очереди: сколько времени ваш запрос был поставлен в очередь. Посмотрите на NewRelic для этого или сделайте это самостоятельно с заголовком HTTP "Начало времени", который Heroku добавляет к вашему входящему запросу (просто выведите сейчас() минус "время начала" в качестве времени очереди).

Когда мне это не удалось, я попытался придумать то, что может пойти не так, и вот список (неортодоксальный? странный?):

1) DNS - вы делаете какие-либо DNS-вызовы в своем представлении? Это может занять некоторое время. Даже DNS-запросы для разрешения имен хостов БД, имена узлов Redis, сторонние поставщики услуг и т.д.

2) Производительность журнала - Heroku собирает все ваши stdout с помощью своего "Logplex", который затем сливается с вашими собственными логдрами, такими услугами, как Papertrail и т.д. Документация об эффективности этого не существует и записывается в stdout из вашего процесса может теоретически блокировать периоды, в то время как Heroku очищает любые буферы, которые могут быть там.

3) Получение соединения с БД - не уверен, какую структуру вы используете, но, возможно, у вас есть пул соединений, из которого вы получаете соединения с БД, и это заняло много времени? Он не будет отображаться как время запроса, это будет блокировать время для вашего процесса.

4) Производительность Dyno - у Heroku есть функция надстройки, которая будет печатать каждые несколько секунд некоторые показатели сервера (load avg, memory) в stdout. Я использовал Graphite для их графического отображения и поиска корреляции между метриками и временем, когда я видел увеличенные экземпляры "спорадических медленных запросов". Это не помогло мне, но могло бы помочь вам:)

Сообщите нам, что вы придумали.