Example: User demand estimation

April 16, 2007

Once the function, behaviour type and usage pattern data have been provided the model starts to produce useful information based on its estimations. The most important of this is the daily function usage estimation. This information is presented on the “Estimated Function Demand” sheet within the model, and provides as estimate, by year, of the average daily usage for each function. This is then used to provide an estimate of the average and peak operations per second for the system. Read the rest of this entry »


The generic system performance profile

April 11, 2007

Generic Performance profile graph

When drawing a graph of the response time performance of a system with increasing load it will usually follow a standard profile, namely:

  •  

    A very low load increasing the load will actually improve the performance of the system slightly. This is because most systems use various caching mechanisms and if there is too little load none of the caches will have data in.

  • As the load increases a near flat region will be experienced, where all requests act as if they have near dedicated resources available to them. Read the rest of this entry »

ITIL and Capacity Management

March 14, 2007

I have been aware for a while that the IT infrastructure library (ITIL) contains a section on Capacity Management. There is, however, relatively little information that is publicly available about ITIL and the way that it is fitted together. (A summary of ITIL is available here.) As a member of the BCS I found a summary of the foundations of ITIL on the 24×7 books site that membership provides access to. Possibly more interesting, however, is the following article that provides some description of the ITIL Capacity Management, along with a simple example of an ITIL Capacity Plan: ITIL Capacity Management Deep Dive Read the rest of this entry »


Monitoring all user interactions

February 14, 2007

 Last year (in this article) I asserted that monitoring of all user operations on an on-going basis was highly valuable. At the time I was not aware of any automated tools to do this task, meaning that solutions would need to be implemented on a per-application basis. In the worst case, this could mean laboriously adding logging statements into application code and then providing analysis mechanism to extract meaningful information from this logging. Read the rest of this entry »


Example: Function definition

January 15, 2007

I will skip the title sheet, which is merely descriptive, and start to work with the function definitions. In this case I highly recommend starting with a few key functions that are likely to provide the majority of the key performance behaviour. If this model turns out to be insufficient at a later stage then add more information as the model develops. This means that the level of detail being worked on remains manageable. Read the rest of this entry »


Performance Model Example

January 15, 2007

I have received feedback that the performance model would be more useful if it was better documented. The is a tour of the model available (here), but that doesn’t make it clear how to apply the model ina typical usage scenario. I have, therefore, decided to illustrate the use of the model using a fictional example. Read the rest of this entry »


Queuing model tools

November 7, 2006

During a recent engagement I needed to use queuing theory based modelling to examine the performance of a system. Searching the Internet I found the JMT open source tools:

http://jmt.sourceforge.net/

Read the rest of this entry »


Improved performance model

November 7, 2006

I have provided an updated performance model on my web site. This includes a number of improvements, mainly centred on data growth modelling and the analysis of function usage where different functions have significantly different usage times within a day. It is available under the “Free Resources” section of the web site.


The value of performance assurance

November 7, 2006

The process of assuring the performance of systems can be expensive. The costs involved can include software development, implementation and maintenance of monitoring systems and hardware investment. It can be easy to forget, however, that a system that performs well has higher value to the business than one that performs badly. Thus, if there is no critical performance problem that needs resolution it can be seen as an ineffective use of resources. Read the rest of this entry »


Validating a performance model

October 7, 2006

A performance model will be full of assumptions and estimates, and yet it is necessary to make important design decisions and capacity choices based on its predictions. This means that it will be necessary to check that it is correct, known as validating the model. Read the rest of this entry »