What strategies would you use to prepare or respond to a large spike of traffic?
Ask HN: How would you handle a large traffic spike (eg. being frontpage on HN)?
1–10 of 32 posts
Re: Ask HN: How would you handle a large traffic spike (eg. being frontpage on HN)?
#2you shouldn't respond rather be prepared.
Re: Ask HN: How would you handle a large traffic spike (eg. being frontpage on HN)?
#3Prepare ahead of time. Short of using an elastic load balancing service, predict when you may have traffic spikes, and choose a cheap-to-implement solution such as request-level load balancing.
Create replicas of your web server processes on different machines for the duration you expect a potential traffic spike. Use a fast dispatcher like nginx[0] as a reverse proxy to load-balance requests to the appropriate replica web server machine.
If you see consistently low traffic, spin down the replicas and remove them from your load balancer configuration.
Re: Ask HN: How would you handle a large traffic spike (eg. being frontpage on HN)?
#4A one-off (or hoped-for) event? I'd just stick CloudFront in front of it...
If I were hoping to build a high traffic site (as in - I expected long-term heavy traffic, rather than a single "spike") - I'd work out how to most easily implement my cms's caching options with CloudFront or S3 or some other CDN.
Most important thing is to make sure a page view doesn't _really_ require a bunch of db hits or personalisation. (Especially not if you're using something like SiteCore or are running super lean with WordPress on inexpensive shared hosting...)
Re: Ask HN: How would you handle a large traffic spike (eg. being frontpage on HN)?
#5This depends almost entirely on what you're doing. If the site at issue isn't dynamic, my suggested action is probably "do nothing", because being frontpaged by HN is not going to tax any computer routinely used to serve web pages in 2017.
If you genuinely have problems, then the question boils down to "What is going to break first?" and whether it makes more sense to harden that or temporarily disable it. If you're a flight search engine and responding to flight searches is just intrinsically costly, then you probably need more capacity and/or a way to "shed load" and redirect folks into some sort of queue or alternative UX ("We're overloaded; give us your email address and we'll get back to you.")
If the dynamism on your pages is something that is incidental to their functionality, fakeable, or chosen simply for programmer convenience, you can dial down the dynamism for the time being via e.g. sticking a cache in front of the page, serving a static HTML version of it, pre-baking the default search/etc rather than recomputing it live for each of the 40k sessions, etc.
The most common "HN killed my website" is probably WordPress being served by Apache with KeepAlive on. That isn't simple to remediate if you continue serving WordPress from Apache; this would be one of my fairly few cases where it's a fundamental technology choice. (It is possible this has changed in recent years, but for a period of several years "apt-get php apache2" would get you an install guaranteed to blow up in production with over 10 simultaneous users.)
Re: Ask HN: How would you handle a large traffic spike (eg. being frontpage on HN)?
#6Caching!
Cache responses where possible and have the webserver serve it instead of going to a dynamic backend (php, node, ruby, python, ...).
Not worked with apache for a while (it is probably sufficiently configurable too), but nginx is quite resilient and makes "basic" caching very easy (proxy_cache and fastcgi_cache should cover you)
Re: Ask HN: How would you handle a large traffic spike (eg. being frontpage on HN)?
#7Is HN front page a large spike in traffic?
Re: Ask HN: How would you handle a large traffic spike (eg. being frontpage on HN)?
#8Caching.
I used to be responsible for sites involved with the Olympics. For 100 weeks traffic was next to nothing. For the two weeks preceding and two weeks during the games there really was spike after spike after spike.
The site basically used nginx with SSI to serve up static content that was generated from Rails. Almost everything we could make static was. We rsync'd files every minute or so across the cluster and would lazy load for content at an individual node if needed.
For dynamic stuff we figured out tricks to use JS, APIs and memory cache dynamic partials. I wouldn't recommend any of that unless you really have the need though.
Re: Ask HN: How would you handle a large traffic spike (eg. being frontpage on HN)?
#9Caching. I used to be responsible for sites involved with the Olympics. For 100 weeks traffic was next to nothing. For the two weeks preceding and two weeks during the games there really was spike after spike after spike. The site basically used nginx with SSI to serve up static content that was generated from Rails. Almost everything we could make static was. We rsync'd files every minute or so across the cluster an…
Did you really use Rync? I figured there might be something more modern.
Re: Ask HN: How would you handle a large traffic spike (eg. being frontpage on HN)?
#10Is HN front page a large spike in traffic?
No.
For the benefit of other folks doing capacity planning: expect peak load of ~25 requests per second [+] in the first few minutes after your thing hits the front page and 50k~80k sessions over the course of a day for a typical article-style UX, coming both from HN and Twitter/etc assisted magnification of HN articles.
[+] For your HTML; you'll of course get the usual multiplication for linked scripts/css/images but you'll come nowhere close to saturating your uplink with those, so the limiting factor is almost certainly processing time for dynamic requests.