Heroku: Обычный 15 минут на простое приложение Rails

Question

Я новичок в Rails и просто развернул свое первое приложение в Heroku (на свободном уровне). Я установил бесплатную пробную версию New Relic и установил контроль доступности для ping my/register/URL каждые 1 минуту. Я запускаю Rails 3.2.13 и Ruby 1.9.3.

У моего приложения нет пользователей и нет запросов (2 запроса в минуту, в основном, из NewRelic). У меня нет фоновых служб или внешних зависимостей. Модель данных проста, и никакие запросы не занимают более 100 мс.

Я получаю полный перерыв продолжительностью ровно 15 минут каждые несколько часов.

Поскольку Heroku только хранит 1500 строк журналов не имеют данных для каждого случая, но вот журнал для 2-го всплеска (мой график -0400, Heroku является UTC).

Полный журнал:https://gist.github.com/jbinto/5495226/raw/ba61ec16d9655287466cfbb9328f59c0171b2df7/heroku.log

Резюме

• 00:56:21 по 01:00:21: Он пыхтит по 1 запросу в минуту в обычном режиме.
• 01:01:55: Последний запрос, который пришел, кажется, не обслуживается.
• 01:02:21 по 01:17:21: 54 H12 (запрос таймаута).
• 01:17:25: PG :: Error (ошибка SSL SYSCALL: EOF обнаружен) (в сторону: я замечаю заявления журнала Heroku находятся в порядке, странно.)

Является ли это PG :: Устранить причину моих проблем или просто симптом? Некоторые Googling показывает обсуждение Postgres ауты на стартер яруса, а некоторые увещевание не используя производственный уровень: https://groups.google.com/forum/?fromgroups=#!topic/heroku/a6iviwAFgdY

Больше StackOverflow: Postgres + Heroku SSL SYSCALL error

И билет Рельсы о авто-переподключение: https://github.com/rails/rails/issues/9421

Это похоже на хороший ключ, но никто, кажется, не решил этого. Похоже, что в Postgres Heroku есть некоторая хладнокровие, и Rails < 4 не выздоравливает от этого.

• 01:17:26 по 01:17:27:. 58 запросов GET являются «обслужен» (я полагаю, эти запросы на клиент давно ушел из-за второй тайм-аут 30 Почему эти запросы все еще идут?)
• 01:17:51: Все возвращается в норму.

Любые идеи? Я открою билет на поддержку Heroku, но не уверен, что я получу где-нибудь бесплатно.

Answer 1

Ответ здесь:

T01:02:21.144033+00:00 heroku[router]: at=error code=H12 desc="Request timeout" method=HEAD path=/register host=www.puckpicks.ca fwd="50.18.57.7" dyno=web.1 connect=1ms service=30000ms status=503 bytes=0

Вы вообще видите эту картину, где один затянувшееся действие начинается коробления очереди для всех последующих запросов.

Маршрутизатор Heroku будет отбрасывать длительный запрос через 30 секунд, но динамик позади него продолжит обработку запроса до завершения. Маршрутизатор не знает об этом, поэтому он отправит новые запросы этому занятому динамику. Этот эффект имеет тенденцию к объединению, и вы увидите очередность в New Relic и, в конечном итоге, ошибки H12 даже для несвязанных URL-адресов, таких как статические активы.

Возможно, вы захотите установить что-то вроде тайм-аута в стойке, что обеспечит также отбрасывание длинного запроса на уровне dyno. В частности, тайм-аут в стойке повышает значение TimeoutError, когда это происходит. https://github.com/kch/rack-timeout

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

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