Estimating System Load

One of the initial steps that every non-trivial project should go through revolves around determining system usage requirements.

Here’s a no-nonsense method for tackling this issue head-on.

1. Anticipate Usage and Usage Patterns

A prudent developer or architect will find out who the end user will be.  He will also find out the anticipated numbers of end users that will be accessing the system.  In addition, he will look at the anticipated usage pattern to look for things like spikes (ie..all users log into the app at 8am on Monday..or users only log in once per year). 

Note: Don’t forget to include integrated applications in the system usage numbers.  They generate load just like human end users.

2. Estimate Future Usage

Assuming the number of end users isn’t fixed over time, you should also estimate future growth.  If the application will be used in house, ask what the hiring trend will look like for the next year.  If this is a web startup, you might look at future revenue (ie..$10/user per month) and determine what an acceptable cap for the system will be (1000 users = $10k/month).  Spend time talking with the customer and find out what is acceptable and within reason.  They will appreciate you setting realistic expectations for them.

Also take time to compare how the numbers change.  Some systems (ie..internal systems) may exhibit growth in usage that’s linear (ie..adding 5 additional users per year).  Other applications may experience exponential growth (ie..the next hot social networking application).  It’s important to be able to recognize those exponential growth apps, as extra care will be needed.

3.  Calculate Anticipated Load

Taking your usage figures, try and give a rough estimate as to the number of calls/requests per second the numbers translate into.  If this were an HR web app and there are 35 people in HR (with no anticipated hiring in the next year), you might estimate the number of calls per second for the entire department. 

35 people * 3 seconds between clicks = ~12 requests per second

4.  Include a Margin of Safety

Taking load estimates and multiplying by 10 will give you a nice cushion for error in your estimates.  In the fictitious example above, we need to validate that our system will handle at least 120 requests per second.

5.  Sanity Check Your Architecture

The initial development done on any system should be a threading of the architecture.  This means wiring each piece of the entire system together, from UI to database and everything between.  This step allows you to vet the high level design of the system.  It also allows you to sanity check your baseline architecture against the usage requirements.  Can the technology you’ve chosen and the deployment you’ve designed handle the anticipated load?  If not, it’s better to find out now, rather than develop the app and find out during the initial deployment.