Previous ◁ | ▷ Next

Advanced Capacity Planning: Analyzing Application Peaks

Tele Columbus GmbH in Hannover, Germany, had a capacity planning problem to solve before the introduction of a large number of additional users of one of their major interactive applications, where number of transaction would be doubled. How much additional CPW capacity was needed?

The application in question was currently in use from many work stations, and could be identified by generic job names A206*, HE*, NI*, PC*, Platz*, TM*, and TS*. But to calculate the additional resources needed it was not sufficient to know the total CPU and/or I/O usage by these jobs, because the usage of this application was varying very much depending on the time of the day, with some rather significant peaks.

To base capacity planning on the total use of resources by the current users would be similar to plan a highway based on the total number of cars per 24 hours, without considering the morning and evening rush hours.

On the other hand, basing the upgrade on the peaks only would likely mean an unnecessarily large investment. It was obvious that a more detailed analysis was needed.



The data required to answer the questions were delivered by GiAPA, Global iSeries Performance Analyzer from iPerformance. This software product collects performance data for all jobs and tasks every 15 seconds. During the subsequent analysis of the data, all jobs and tasks not showing any signs of having or causing performance problems are normally removed from the final exception reporting data, but an option allows *ALL data to be kept.

When all data is kept, the GiAPA report options allow very flexible, user defined selection criteria, amongst others capable of automatically accumulating all data belonging to the job names listed above, and present the results in various ways. In this case two reports were selected:

A histogram showing in how many 15-second collection intervals each CPU percentage was used by the jobs selected.

A report by 15 seconds interval showing the use of CPU and I/Os by type by the selected jobs and by all jobs and tasks.



The first report documented that whilst peaks reaching almost 100 % of the total available CPU did occur, this happened so rarely that it would be an overkill to base the upgrade on these peaks and double the CPW capacity. Satisfying the CPU required by the application in 99.5 % of all cases could be achieved with a considerably smaller upgrade.

The second report, where also totals for disk I/Os were available, showed that the disk I/O capacity needed to accommodate the additional workload apparently was available, even considering all the other applications running on this server. It also confirmed the results from the histogram report: Other applications running in parallel to the selected jobs did not need so much CPU resources that a larger upgrade was needed.

So although GiAPA never was intended to be a capacity planning tool, its ability to deliver any kind of job performance data down to intervals of only 15 seconds can produce reports enabling management to base hardware upgrade decisions on a more correct basis.