Replace resources cache with stale headers

[joanniclaborde]

Since most Solidus sites (those by @SparkartGroupInc at least) are behind a cache like Fastly, and use resources proxied with a cache too, it's not very useful for Solidus to have its own resources cache. This pull request:

• Removes the resources cache entirely, all resources are fetched at every request. This makes each request slower, but resources are fresher.
• Returns stale-while-revalidate and stale-if-error caching headers, set to 1 day. To prevent the user from waiting for the longer pages.
• Removes the Last-Modified header. Its value was random anyway, ETag is much more accurate.
• Sets the page's Cache-Control: max-age and Expires headers to the nearest resource expiration date. This will make resources changes appear quicker on the live sites. This new expiration date is capped at 5 minutes, in case we get resources will really long expirations.
• Changes a resource's default freshness from 1 to 5 minutes. To mimic Storyteller's behaviour.

[pushred]

And here we are full circle — https://github.com/solidusjs/solidus/issues/31

Code looks fine, I'm all for slimming solidus down. I am curious about concurrency however. Have you done any surge testing to get an idea?

Looking at a range of sites for the past 24 hours in Heroku most seem to only get about ~20 requests/min (or less), with some spikes here and there doubling that. I wish I had much more historical data to review but that doesn't seem like much to be worried about. With resources taking much longer to fetch though I wonder about worst case scenarios where a request for a page could start to near Heroku's hard request timeout of 30 seconds. If we're being scanned by a crawler a fair number of requests across a range of URLs would be requested, at some point won't requests start to stack up even with Fastly in front?

In those cases at least Fastly would keep retrying, maybe having a throttling effect, but I'm wondering about the threshold (and possible scenarios leading to it) that leaves us no choice but to add additional dynos. That 1 second cache was maybe targeted at some issues in this area but there's nothing documented from that time. Disappearing resources due to timeouts were definitely a thing though for awhile..

[joanniclaborde]

I did some local tests with siege and youngmoney, and it's pretty easy to overload Solidus. The home page has 5 resources, so if you bombard the site with 10 concurrent requests, the bottleneck is of course the network (Solidus is opening 50 connections at once).

I also did a few more "realistic" tests, like launching 5 site crawlers at the same time on youngmoney.com. The site held just fine, even though the general response time of Heroku was higher.

The key is of course a good CDN. This PR moves the performance considerations from Solidus to Fastly. With the 24h stale-while-revalidate setting, Fastly should eventually be able to serve the whole site from cache, except for older posts that mostly get their traffic from bots once in a while.

I think we should run this code live with a few sites for some time, and see how it goes. So far it seems to be working fine, but if problems arise we'll have to trade "resource freshness" with "performance"...

[pushred]

:+1: let's see how it goes, the resource freshness is pretty fresh right now!

[pushred]

This is now running on thelumineersfanclub.com

[joanniclaborde]

You can also use the #139 branch, for a faster response time.