You’re a lucky guy. Your web app runs on the biggest server available. It takes a mere 10% CPU and has tons of free memory available. Everything is great. Well, not everything… One tiny, little detail might jump out of the darkness at the worst possible moment…
That tiny, little detail is a collection of inefficiencies you’ve introduced over time. On a dedicated, big iron server, it doesn’t really hurt if a database query takes 0.2 sec. And you didn’t care that the very same query took 2s on your local development box, because you knew it would be “fast enough” (™) on the live site. Well, you’re right…right up to the point where your application has to scale, when you’ve got enough users on the system that even your “big iron” begins to cough and sputter.
Scale-up is not an option if you’re already using top-of-the line hardware
If you’re already running the biggest server available, it’s really hard to scale that box up. So, your remaining options are:
- Scale-out to other servers
- Optimize your code
Both options are tedious – especially if your site is under heavy fire. It would be so nice to just upgrade to a bigger server and buy yourself a couple of weeks to optimize your app and prepare for scaling.
Avoiding over-capacity
One way to avoid crashing into such a road-block is to run your application on smaller hardware from day one. Even if you’ve got big iron available, it’s a good idea to put your web app inside a virtual machine, limiting its resources. By doing this, you’ll get early warnings of scalability issues. If you write a query which takes too long, you’ll notice on the same day. If your application gets a load spike, you have some breathing room to scale it up while you’re preparing the scale-out architecture. Working with constrained resources is a good thing because it forces you to do a better job right from the start!
Agile Web Operations 