How I may help
LinkedIn Profile Email me!
Call me using Skype client on your machine

Reload this page Capacity Projection Management with Performance Testing

This presents a way of presenting the results of performance testing and capacity planning for use by several professionals. Let me know what you think.


Site Map List all pages on this site 
About this site About this site 
Go to first topic Go to Bottom of this page


Copyright 2004-2013 Wilson Mar. All rights reserved. Pop-up this diagram to its own window

Set screen Why Load Test?

    The value of Performance Testing is to warranty, that the system is fit for use (has the appropriate level of availability, security, and performance).

    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 Managerson this page to anticipate the true capacity of IT resources: whether it can really support the peak workloadson this page anticipated.

    Stress (Overload) testingon this page 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) testingon this page

    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.

Go to Top of this page.
Previous topic this page
Next topic this page

Set screen Sample Capacity Projection Calculations

  1. 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.
  2. 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.

  3. 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).

  4. 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.

  5. 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.


    BEZVision (BEZProphet until Oct. 2007) provides predictive performance management for applications and databases that includes "what-if" evaluation of the impact of additional users, new applications, server and other hardware consolidation, moving to an new DB release, etc.

Go to Top of this page.
Previous topic this page
Next topic this page

Set screen Next


Bookmark this page:

Go to Top of this page.
Previous topic this page
Next topic this page
Performance Engineer Life Role Site Map Performance and Capacity Management... Syndicate this list of links:

Feed Validity Checked RSS 2.0 XML feed
Feed Validity Checked Atom 1.0 XML feed


How I may help

Send a message with your email client program

Your rating of this page:
Low High

Your first name:

Your family name:

Your location (city, country):

Your Email address: 

  Top of Page Go to top of page
Previous topic this page

Human verify:
Please retype: