Проблемы с обслуживанием статических активов Heroku с Sinatra?

У нас есть очень большое приложение с МНОЖЕСТВОМ магистрального кода по всей нашей кодовой базе... Очевидно, что загрузка 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%, а время обслуживания увеличивается более чем в два раза. Что здесь происходит??

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


assets optimization heroku sinatra
person Brad Herman    schedule 17.02.2012    source источник
comment
Это звучит как вопрос к Heroku, а не к программистам. Может ли это число быть средним временем запроса, и поэтому, конечно, отправка огромных файлов займет немного больше времени на файл, чем (много) крошечных файлов?   -  person Phrogz    schedule 17.02.2012
comment
Действительно - одна СЕКУНДА, чтобы обслужить файл javascript длиной 30 КБ?   -  person Tom Andersen    schedule 22.02.2012

Ответы (1)


arrow_upward
2
arrow_downward

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

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

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

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

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

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

person Tom Andersen    schedule 22.02.2012