Проблемы обслуживания статического актива Heroku с Синатрой?

Question

У нас очень большое приложение с тоннами магистрального кода по всей нашей кодовой базе ... Очевидно, что загрузка примерно 100 js-файлов является большой нагрузкой на HTTP-запросы от Heroku, и мы решили упаковать их, чтобы ускорить процесс.Мы решили использовать гем sinatra-assetpack , чтобы сжать и упаковать их, чтобы уменьшить общий размер и HTTP-запросы.Удивительно, но даже несмотря на то, что мы сэкономили приличное количество места и сократили количество HTTP-запросов почти на 100, наши журналы в Heroku показывают увеличение серверного времени по запросам GET!

Я изо всех сил пытаюсь понять, почемуэто может происходить, но вот быстрая распечатка:

Before assetpack:
heroku[router]: GET xxxx dyno=web.5 queue=0 wait=0ms service=888ms status=200 bytes=35726

After assetpack:
heroku[router]: GET xxxx dyno=web.6 queue=0 wait=0ms service=1862ms status=200 bytes=30103

Размер запроса уменьшается на 15%, а время обслуживания более чем удваивается.Что здесь происходит ??

edit: я должен упомянуть, что assetpack создает сжатые версии при развертывании, а затем подает их из памяти ... Возможно, это может оказать влияние?

Answer 1

Отредактировано:

Кажется, я понял это. Если у вас есть приложение heroku, которое спит - все бесплатные приложения спят, если они не используются - для запуска приложения Heroku требуется около секунды или около того. Вот почему вы получаете 860 мс для загрузки. Затем, когда вы добавляете в менеджер активов, у него есть много дел, поэтому занимает больше времени. Вам нужно нажать 10 раз подряд, чтобы увидеть изменения в скорости.

Например, первоначальное попадание в мое приложение занимает 860 мс, а второй, третий и т. Д. Вызов занимает около 5 мс.

Старые мысли:

«Создает сжатые версии при развертывании» - даже если оно работает правильно, вы будете развертывать для каждой версии своего приложения (для каждой dyno) или более - если приложение нуждается в перезагрузке по другим причинам, таким как сбой, и т.д.

Еще одна мысль: доктора говорят «поддержка героку», что бы это ни значило. Но они также говорят о «очистке кеша» - что если каждый dyno вашего приложения по-разному понимает, что такое специальный номер очистки кеша - так что dyno # 1 говорит, что special # is 892094.js, а dyno # 2 - 928449. js, а так как динамо назначается случайным образом - у вас есть побои.