Scaling Dynos с Heroku

Question

В настоящее время у меня есть рубин на рельсах, размещенном на Heroku, который я контролирую с помощью новой реликвии. Мое приложение несколько лага при его использовании, и мой новый монитор Relic показывает мне следующее:

Учитывая, что большую часть времени тратится на заказе очереди, значит ли это мое приложение будет масштабироваться лучше, если бы я использовали дополнительные рабочие динамометры? Или это то, что я могу исправить, оптимизируя свой код? Извините, если это глупый вопрос, но я полный новичок и ценю всю помощь. Благодаря!

== EDIT ==

Просто хотел убедиться, что я был кристально ясно по этому вопросу до того, чтобы выложить дополнительные бабки. Так New Relic также дал мне следующую статистику на стороне браузера, как вы можете увидеть здесь:

Этот график показывает, что большая часть времени, затрачиваемого пользователем в ожидании веб-приложения. Могу ли я объяснить это тем фактом, что мое приложение проводит большую часть своего времени в очереди запросов? Другими словами, что время реакции 1,3 секунды, которое испытывает конечный пользователь, в настоящее время является чем-то, что только оптимизация кода мало что может сократить? (В принципе, я спрашиваю, нужно ли мне тратить деньги или нет) Спасибо!

Answer 1

Запрос на очередность в основном означает «ожидание появления веб-экземпляра для обработки запроса».

Таким образом, самый простой и быстрый способ получить некоторую скорость во время отклика будет заключаться в увеличении количества веб-экземпляров, чтобы ваше приложение быстрее обрабатывало больше запросов.

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

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

редактировать

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

1. Если у вас есть запрос в очереди это потому, что запросы ждут веба экземпляров становятся доступными для обслуживания их просьбы. Добавление большего количества веб-экземпляров напрямую влияет на это, предоставляя больше доступных экземпляров.

2. Возможно, вы могли бы оптимизировать приложение настолько хорошо, что значительно сократили время обработки каждого запроса. Если это произошло, это уменьшит порядок запросов, если запросы будут ждать более короткого периода времени, чтобы обслуживаться.

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

Удачи!

Answer 2

Я просто хочу выбросить это, хотя на этот конкретный вопрос ответили. Я нашел этот пост в блоге от New Relic и ребята на Engine Yard: Blog Post.

Т.Л., др здесь является то, что запрос Очереди в Нью-реликвия не обязательно запросы на самом деле выстраиваются в очереди и не будучи в состоянии получить обрабатываются. Благодаря тому, как New Relic вычисляет эту метрику, она по существу считывает временную метку, установленную в заголовке nginx, и вычитает ее из Time.now, когда метод New Relic получает ее. Тем не менее, New Relic получает бег после вызывает вызов любого из ваших кодов before_filter. Итак, если в этих before_filter s есть куча интенсивно вычислительного или интенсивного кода базы данных, вполне возможно, что то, что вы видите, на самом деле требует задержки, а не очереди.

Вы можете проверить очередь, чтобы увидеть, что там находится. Если вы используете Passenger, это очень просто - просто введите passenger status в командной строке. Это покажет вам массу информации о каждом из ваших пассажиров, включая количество запросов, находящихся в очереди. Если вы запускаете с предшествующим watch, команда будет выполняться каждые 2 секунды, чтобы вы могли видеть, как очередь изменяется со временем (так что просто выполните watch passenger status).

Для серверов Unicorn это немного сложнее, но есть рубиновый скрипт, который вы можете запустить, доступный here. Этот скрипт фактически проверяет, сколько запросов сидит в гнезде единорога, ожидая, что его подхватят рабочие. Поскольку он исследует сам сокет, вы не должны запускать эту команду чаще, чем ~ 3 секунды или около того. Пример в GitHub использует 10.

Если вы видите большое количество запросов в очереди, то добавление горизонтального масштабирования (через большее количество веб-работников на Heroku), вероятно, является подходящей мерой. Если, однако, очередь низкая, но New Relic сообщает о высокой очереди запросов, то, что вы на самом деле видите, это задержка запроса, и вы должны изучить свои before_filter s и либо охватить их только теми методами, которые им абсолютно необходимы, либо работать по оптимизации кода, который выполняют эти фильтры.

Я надеюсь, что это поможет любому, кто придет в эту тему в будущем!