Performance Testing for Capacity Management

Why Load Test?

Scability Testing buys us confirmation of predictions about what will happen before it happens, buying the lead time to do the right thing when additional capacity is needed.

Load testing provides measurements for Capacity Managers to anticipate the true capacity of IT resources: whether it can really support the peak workloads anticipated.

Stress (Overload) testing identifies the predicted point of failure where servers fail to handle loads.

The biggest actionable concern is time needed to recover from overload.

Most web hosts today control overload by issuing "Service Unavailable".

The existing capacity of the system is ideally defined by the usable capacity at a point of load where users notice slow response time is noticeable. This is obtained by conducting Speed (performance) testing

The difference between the current load (the actual demand) and usable capacity from load testing is the real reserve capacity — the amount of "head room" for growth or the ability to handle variation in demand.

The work of capacity management is finding a balance between the unused expense of having too much idle capacity against the risk of reputation-damaging problems from not enough capacity.

Upgrades to capacity can be smoother if there is what the ITIL methdology calls a common Forward Schedule of Changes (FSC).

Lead time include time for planning and testing, which can be shortened by a more agile approach.

The approximate date when usable capacity will be reached can be calculated by dividing into the usable reserve capacity the rate capacity usaage is growing (per day). Subtracing the lead time from that date yields the the Trigger Point when upgrade work should begin.

Subtracting the amount of capacity growth during the lead time yields the threshold of workload which should trigger an upgrade.

Thus, this chart gives actionable meaning to production monitoring.

Sample Capacity Projection Calculations

An analysis of archived Weblogs reveal the current daily peak of 300,000 hits per hour and (dividing by the average of 10 resources per page as determined using HTTPWatch or YSlow) yields 30,000 pages per hour.

A meeting with analysts (using Google Analytics) identify that each user transaction averages just 3 pages.

So 30,000 / 3 means that there are currently 10,000 user transactions per hour.
Divided by 60 minutes in an hour means 166.667 transactions per minute.
Divided by 60 seconds in each minute means 2.778 transactions per second.

A conversation with Marketing department obtained the prediction of a 100% increase in workload by the same time next year.

So this means that the workload rate will double to 600,000 hits per hour or 60,000 pages per hour or 20,000 user transactions per hour.

The amount of workload growth is 60,000 pages - 30,000 pages current = 30,000 pages per hour.

Since each day is 100% / 365 = 2.74%, the daily growth rate is 30,000 * 0.0274 = 82.2 more pages per day growth each day, on average (assuming a linear growth pattern).

Load test runs find that the current system fails when load reaches 60,000 pages per hour. However, response time degrades after 50,000 pages per hour.

Subtracting the current capacity means there are 50,000 - 30,000 = 20,000 pages per hour of reserve capacity growth remaining.

This translates into 20,000 / 82.2 = 243 days of growth remaining.

A conversation with Operations reveals that it takes 40 days to order, receive, install, configure, test, and switch over before a machine can be used. That is when there is no queue in Operations, which is generally 10 days.

This means that upgrading action should begin no later than 40 + 10 = 50 days of lead time before the usable capacity limit is reached.

If the predicted growth actually occurs accurately, this trigger point will be reached in 243 - 50 = 193 days.

During the lead time, the anticipated growth in workload over 50 days * 82.2 per day * 24 = 98,640 more pages per hour.

Working backward, the workload trigger point is when the workload reaches 50,000 - 10,686 = 39,314.

Your first name:

Your family name:

Your location (city, country):

Your Email address:

Email updates (subscribe)

Top of Page

Human verify:

Please retype:

Capacity Projection Management

Why Load Test?

Sample Capacity Projection Calculations

Next