HN Explorer

Ask HN: How do I prevent "Service Unavailable" on a Show HN?

13 points by soneca ↗ HN
This is all too common. A "Show HN" is a hit, but the server can't stand the traffic.

I am planning a Show HN (hoping it is a hit) of a AWS hosted SaaS. What measures should I take to support all the traffic from HN?

6 comments

[ 4.4 ms ] story [ 31.1 ms ] thread
cloudflare
You could use CloudFlare as a front end to take some of the load.
dirktheman
AWS offers autoscaling for EC2 instances: http://aws.amazon.com/autoscaling/. Additionally, use their Cloudfront (or CloudFlare, which offers better value and is easier to set up) CDN. Looking forward to your launch!
Greatri
You could load test your website using a tool like blitz.io. Test for, say, 500 simultaneous users and see what happens :) Just don't get caught up in premature optimization too much, I'd rather the website went down for a short while than never hitting the front page at all.
antsar
Thanks for the blitz.io reference. I've been looking for a tool to load-test some personal projects, and others I found didn't have a satisfactory free tier.
xwowsersx
Didn't know about blitz. Looks good, thanks.
bmelton
Not all SaaS are equal. The answers for this question are extremely different between Spotify and Basecamp, for example. The scaling path is rarely identical for any two applications.

That said, there are common things that can be done, many of which have already been mentioned.

For AWS, make sure that you have at least two EC2 instances running, and they're configured to sit behind an elastic load balancer, then make sure that autoscaling has been set up.

As dirktheman says, Make sure that you're sitting behind Cloudfront for caching benefits. Also, make sure that your static files are all being hosted appropriately on a static server (Nginx, Apache, etc) and not by the application server.

Consider implementing memcache. This may or may not fit every applications, but if you have some common queries that are likely to be hit during a traffic spurt, having them resident in memory takes some of the load off of the database, if there is one.

Assuming RDS, definitely be using Multi-AZ instances, and also consider setting up read replicas. If your application is more likely to be read than written to, read replicas are an easy way to ensure that the application will still work for those writing to it (generally, paying customers) while mitigating traffic spikes typically common to media blitzes. Also, having an architecture that supports the easy addition of read replicas affords greater scale-up-ability.

Above and beyond that, everything's pretty application-specific. If you wrote the app in Rails, try to find a Rails-production-ready checklist. Same thing if Django, Java, whatever.

Good luck.