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.

Related Articles:

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

4 Responses to Estimating System Load

  1. Bender says:

    Nice article, but multiplying the end result by 10 seems like an overkill for most areas. What is the point of estimation if we end up purchasing 10 servers when we only need 1? A factor of 2 or 3 seems more acceptable to me.

  2. Evan says:

    @Bender

    Using a factor of 2 for your margin of safety is still somewhat risky due to the fact that our numbers won’t be precisely known ahead of time. In my example above, if the users are clicking every 1.5 seconds instead of 3, we’ve doubled the peak load and eroded the margin of safety to 0. You don’t want to design to run at exactly peak capacity. An order of magnitude (x10) is really what you want to be safe.

    Of course, there may be edge cases where a 10x margin of safety is too expensive, but that’s something we can tackle on a case by case basis. Our general rule of thumb is to stick with that 10x mark.

    The point is to get yourself into the general ballpark–not to be precisely accurate. This exercise is useful as a step to reduce risk from your project. The margin of safety is critical for that since your numbers won’t be precise during esitmation.

  3. Evan says:

    @Bender

    The other important thing to note (using your example) is that if you are seeing numbers that tell you that you will be maxing out an entire machine, your design had better be capable of running on 10 machines. When all the meat goes on the bones of the architecture, it’s a very distinct possibility that the deployment of your application will need at least 3 or 4 machines. Designing an application which wasn’t meant to scale beyond 1 machine in that scenario introduces considerable risk into the project.

    But, determining the actual number of machines needed is something we can figure out much later in the development cycle. We need to validate the architecture first.

  4. Bender says:

    You are right, in the end it is really a question of good judgment for each specific case. Having a ballpark figure at that point really helps in choosing the major aspects of the proposed solution. It might not sound like it, but I also tend overestimate, rather than to underestimate. Basic engineering principle :)