What does your web stack do when a user hits refresh?

http://www.shopify.com/technology/7535298-what-does-your-webserver-do-when-a-user-hits-refresh#axzz2NzuJvlBY

by gravitronic • 13 years ago

29 10 13 years ago

shopify.com

tyw• 13 years ago

that's awesome. does/could something like this exist for apache?

gravitronic4• 13 years ago

Hey folks - I wrote the blog post & the unicorn patch. If you've got questions, I'm watching the thread.

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.

brokentone2• 13 years ago

Really interesting (although really unique) issue, and solid solution. Obviously this greatly differs for various use cases. In the news industry we see similar behavior at peak traffic, although not at this degree, and for the most part caching deals with this issue.

gravitronic4• 13 years ago

Makes sense, and you're right that it's a unique issue.

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.

brokentone2• 13 years ago

I'd have to imagine that you're doing more granular caching... perhaps of queries or widgets? I don't mean to say it's uniqueness makes it irrelevant for the rest of us. Nice writeup that can teach us all something either way.

stanleydrew2• 13 years ago

This is quite clever. But why wouldn't you want this to be the default behavior and have a configuration option to disable it? Are there more situations in which you really want to process a request even when the client can't get the response than the opposite?

gravitronic4• 13 years ago

Unicorn processes millions of requests per minutes for some very large companies. Changing the default actions of a core part of the web stack in a version bump could have terrible consequences for some use cases.

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.

stanleydrew2• 13 years ago

I don't disagree at all with the decision to keep the standard behavior as default for now. For something as critical as an HTTP application server you definitely don't want any surprises.

I just wanted to get your thoughts on the tradeoffs and what you think is appropriate for the majority of use-cases.

X-Istence• 13 years ago

Does this work for unix domain sockets as well? I'm not familiar enough with unix domain sockets.

Also, would something similar be possible using uwsgi/nginx for example?

What does your web stack do when a user hits refresh?

Related Stories