Home/ Questions/Q 7536487
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-30T06:35:14+00:00

We have a very large app with TONS of backbone code throughout our codebase…

  • 0

We have a very large app with TONS of backbone code throughout our codebase… Obviously loading 100 or so js files is a big strain on HTTP requests from Heroku and we decided to package them up to speed things up. We decided to use the sinatra-assetpack gem to compress and package them to reduce overall size and HTTP requests. Surprisingly, even though we saved a decent amount of space and reduced the number of HTTP requests by nearly 100, our logs in Heroku show an INCREASE in server time on the GET requests!

I’m struggling to understand why this may be happening but here’s a quick printout:

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

The size of the request goes down by 15% while the service time more than doubles. What is going on here??

edit: I should mention that assetpack builds the compressed versions on deploy and then serves then from memory… Perhaps that could have an impact?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Edited:

    I think I figured it out. When you have a heroku app that is sleeping – all free apps sleep unless in use – it takes Heroku about a second or so to boot the app. That’s why you get 860 ms to boot. Then when you add in the asset manager, it has a lot to do, so takes more time. You need to hit it 10x in a row to see changes to the speed.

    For instance, the initial hit to my app takes 860ms, but the second, third, etc call takes about 5ms.

    Older thoughts:

    ‘Builds the compressed versions on deploy’ – Even if its working right you will deploy for each version of your app that runs (each dyno), or more – if the app needs a reboot for other reasons, like a crash, etc.

    Another thought: The docs say ‘heroku support’ whatever that means. But they also talk about ‘cache busting’ – what if each dyno of your app has a different idea of what the cache busting special number is – so dyno #1 says the special # is 892094.js, while dyno #2 says 928449.js, and since dynos are assigned at random – you have thrashing.

    • 0