What does your web stack do when a user hits refresh?
shopify.com
shopify.com
This isn't a magic bullet that'll be good for everyone. Since we're processing money, we prefer to make people wait instead of returning them an error when busy, so we opt towards larger queue lengths instead of erroring early.
That increases the chance a user's been around long enough to get disgruntled and hit refresh, which is where this patch shines.
In flash sales our page caching solution becomes less than useful, because every sale invalidates the page cache (in case their shop template changes to reflect quantity). We cache individual records as well with our open-sourced https://github.com/Shopify/identity_cache gem but still have to render the liquid template.
You're probably right that this is ideal default configuration, and maybe in the future it will be defaulted to on.
Right now though the best thing would get people who experience this type of problem to try the configuration change and report their findings.
I just wanted to get your thoughts on the tradeoffs and what you think is appropriate for the majority of use-cases.
If, under load, you can gracefully return an error and your user will just come back later (like the twitter fail whale), then you might as well keep your queue lengths short which close the window where a waiting user will hit refresh.
If you have some requirement that prevents the above, and have large queue lengths, then this may be very useful for you.
As well, some server configurations might not like getting the first part of the HTTP response much before the rest of it. Nginx will just buffer it all before returning the entire response to the client so it doesn't affect packetization of the response sent back to the end-user.
Also, would something similar be possible using uwsgi/nginx for example?