TTFB can be ~30s for Thimble servers

[humphd]

I often see Time To First Byte (TTFB, https://developer.chrome.com/devtools/docs/network#resource-network-timing) times from bramble.mofostaging.net and thimble-beta.webmaker.org in the 30s range. It just seems to wait forever to respond with anything. I don't want to venture what's causing it, but it's pretty common, especially loading in a tab that isn't a refresh.

Here's an example of what I mean:

Here you can see it's taking 27s between the time the browser requests the HTML page, and when it actually starts downloading it. The download itself is fast, too. Where is it for those 27s?

[humphd]

We're shipping the new Thimble on Friday of this week, and I'd love to get to the bottom of this before then. It's almost like it's spinning up the server in order to service my request.

cc @simonwex, @davidascher, @hannahkane, @sedge, @gideonthomas

[sedge]

@humphd My guess is that this only happens once, and then things load normally?

Both apps (thimble & publish.wm.o) run on free heroku dynos, meaning that they idle after a while. Exactly as you said, they spin up on demand and remain active for a set period of time before idling again.

@jbuck @simonwex What do you want to do about this?

[jbuck]

Copy-pasting our IRC conversation:

[10:43:44]  <humph> jbuck: "You have mail" https://github.com/MozillaFoundation/mofo-devops/issues/155
[10:43:55]  <jbuck> humph: I saw
[10:44:01]  <jbuck> and, you're actually not wrong!
[10:44:01]  <humph> wtf is that about?
[10:44:12]  <humph> it's starting the node app?
[10:44:19]  <jbuck> so, I looked at the Heroku dyno config, and it was using the Heroku free tier
[10:44:33]  <jbuck> which sleeps your application after 30 min or 60 min of inactivity
[10:44:44]  <humph> I think we should move staging off sedge's account(s)
[10:44:46]  <humph> and onto something mofo
[10:45:12]  <humph> so this is heroku-only then?
[10:45:19]  <humph> I *thought* I'd hit it on prod too
[10:45:23]  <humph> but maybe I imagined that
[10:54:35]  <humph> !summon gthomas
[10:54:39]  <humph> !summon sedge
[10:55:26]  <jbuck> when it receives a request on the free tier, it'll start up the dyno again
[10:55:42]  <jbuck> when I tested that behaviour myself, it took about 10 seconds for start-up
[10:56:18]  <humph> I did a test within the past hour, so I likely triggered it to start
[10:56:24]  <humph> when it's bad, it's 30 seconds bad
[10:56:32]  <jbuck> so, I'm not sure where the extra 20 seconds are coming from, but for now I've put the apps on the Hobby tier, which means they'll never sleep
[10:56:51]  <jbuck> so you *shouldn't* see the 30s wait behaviour, assuming I'm correct in diagnosing the cause
[10:57:00]  <humph> great
[10:57:02] humph    tests again
[10:57:04]  <jbuck> so, if you do see it, lemme know
[10:57:12]  <jbuck> because then it means it's something else :)
[10:57:20]  <humph> thanks for dealing with this fast

[ashleygwilliams]

just jumping in here- i think sedge is right on point. ive seen this on several other apps i have where the clienr and server are on diff free heroku dynos

Sent from my iPhone

On Aug 24, 2015, at 11:05 AM, Kieran Sedgwick notifications@github.com wrote:

@humphd My guess is that this only happens once, and then things load normally?

Both apps (thimble & publish.wm.o) run on free heroku dynos, meaning that they idle after a while. Exactly as you said, they spin up on demand and remain active for a set period of time before idling again.

@jbuck @simonwex What do you want to do about this?

— Reply to this email directly or view it on GitHub.

[sedge]

@jbuck Can you also upgrade the production publish.wm.o to a hobby dyno?

[jbuck]

Done!

On Mon, Aug 24, 2015 at 4:11 PM, Kieran Sedgwick notifications@github.com wrote:

@jbuck https://github.com/jbuck Can you also upgrade the production publish.wm.o to a hobby dyno?

— Reply to this email directly or view it on GitHub https://github.com/MozillaFoundation/mofo-devops/issues/155#issuecomment-134362891 .

[sedge]

Thanks! Feel free to close.