Thursday, September 4, 2008

Capacity Planning

Capacity planning is one of those areas that is in the no-man's-land that I call "things that are not my job but if done wrong have the ability to give my team a really miserable day".

Therefore I care deeply about capacity planning and specifically about how well the team that does this actually does it.

What Is Capacity Planning?
Capacity planning is the art of deciding how big/how fast/how reliable/how configured a system is required to meet the customer's needs. Basically, your customer wants to do X; what does the system that lets him do that look like?

Stated Requirements
Certain requirements will be stated explicitly. The user will say - sometimes after some prompting - that he needs to support 150 concurrent users, for example. The basic things almost all applications will need to consider are:
  • total number of users (peak usage)
  • average number of users (concurrent usage)
  • amount of data read, written, modified, deleted
  • hardware restrictions (if any)
  • windows of usage (e.g., what is time restricted?)
Derived Requirements
Once you have your list of stated requirements, there are certain requirements you can derive based on the inner workings of your system. These are things the customer doesn't know or doesn't state explicitly, but that are required to keep your system happy. For example, maybe your system works best when the disks on the server are no more than 70% full. Derived requirements are much more specific to your application, but tend to include things like:
  • data access patterns that will influence cache usage
  • available disk space and usage
  • power and cooling requirements
  • network configuration requirements
Once you have your requirements capacity planning is a case of simple calculation. The only real trick here is to be conservative in your rounding. If you have a throughput requirement, round up. If you have a system speed, round down. What you're specifically calculating is dependent on your specific application.

For a web app, for example, we might say that a single web server can support 50 simultaneous users. If we expect to have 100 of 'em, well, we need 2 web servers. If we can support 100 simultaneous requests on our app server, and we expect to peak at 40 simultaneous page loads, each of which requires 10 requests, then we're going to need 4 app servers. And so on and so forth. The calculation isn't the hard part here. Once we've done all our calculations, apply the rule of conservatism and pick the largest overall environment. That's what we need.

In the end that's all capacity planning is. Consider your system variables, find out your load, and start calculating how much of everything you need. There's an art to asking the right questions that only comes with practice, but better to ask than to get caught by surprise after implementation!

No comments:

Post a Comment