I hate slow websites. You hate them too. If you need to fix a slow site, this series is for you!
Making sites perform is something I do. Since there's not enough fast websites out there, I figured that if I blogged about it, maybe somebody (you?) will listen, contribute ideas of their own, and we can all get better at it. Then, maybe, I can finally stop getting so angry when I click on a link and nothing happens!
Series Index
- (this post) - Hardware Is A Last Resort
- Follow The Evidence
- Whack-a-mole
- Page Request Theory
Today's topic is...
Hardware Is A Last Resort
99% of sites on the internet can be served by a $40/mo VPS with 500M of RAM.
Unless you work for a major website - in which case you probably already have a performance ninja or sysadmin team - you don't need more. Throwing hardware at a site to make it scale is worthwhile after you have exhausted all other options to make the site perform. Cloud servers may be cheap, but 10 minutes spent looking for the biggest performance holdup on your site has an exponential ROI.
How does that work? Let's say your bottleneck is RAM, and your site can handle 20 concurrent requests per server. If you just buy servers, you'll get to 100 concurrent requests at five servers. But if you find an easy change that lets you handle 30 concurrent requests, you get there with just four servers. And if you want 1,000, you would have needed 50 servers - but now only need 34.
Where does the exponential ROI come in? It's in the accumulated cost of running those servers as your site grows:
Over time and site growth, small time investments add up to big savings
This graph assumes a 10%/mo increase in requests. While this growth isn't limitless of course, you can see why the likes of Google and Facebook put so much effort into squeezing just a little more out of their hardware. If you get big, you'll save plenty of money over time.
The other reason it's exponential is that in general, there's plenty of low hanging fruit around, which can allow you to get a 10x increase in concurrent requests. I'll share some ideas on those in future posts.
What about smaller sites? There's a cost even from moving from one server to two. Not only did you just double your hosting bill, you made the architecture relatively much more complicated (as now you have firewalls to deal with as well as two machines to keep patched).
If you're serving sites en mass, the maths works out again - if you can split the load down the two servers in a sensible way. This is probably a web/db split. But again, this only makes sense if you know that your one server can't handle web and db loads. Until you know, look for easier wins.
Next post: Follow The Evidence
Like this post? Subscribe to my RSS feed and follow me on twitter to hear about new posts early.
Want to share this post? Tweet
Hi and welcome! In 2009 I quit my job to become an entrepreneur, founding 
