Daily or weekly performance reports are useful aids to performance management. They let you and your colleagues understand what is happening over a relatively short timescale, so that immediate or recent problems can be addressed and rectified.
As mentioned previously, monthly (or less frequent) reports are most useful if they include an element of trending. This gives the significant additional benefit of identifying likely dates in the future before which action will have to be taken in order to avoid potential problems.
This shows two months' worth of data about the total CPU utilisation of a particular server, with a trend line applied.
As shown, the analysis window informs us that the trend line will reach a value of 70% on 17th June. There may be a good reason for wanting to know when the trended daily average CPU utilisation will reach 70%. This is a popular value among performance analysts. It is the typical maximum value beyond which you would not want to run a server processing a critical workload. Although it appears a relatively low value, remember that this trend is based on a daily average, so it allows for some normal variation during the day.
Normally, the best way of determining whether 70% (or any other particular value) is an appropriate cut-off point is to carry out analytical modelling of the system being studied. This will show the performance impact of running at that loading level.
At this point, we are assuming an environment where a chart and its associated trend can be updated automatically. The previous chart covers January and February. Suppose it was generated by an automatic reporting mechanism that produces a new year-to-date report on the first of every month. The next graphic shows the chart that was generated on April 1st, with the trend automatically re-calculated to fit the new March data as well as the previous data.
The analysis window now shows a revised projection for 70% total utilisation - it will not happen until 20th August. Clearly the trend has changed.
Linear trends are extremely useful however, they have a particular shortcoming. Suppose you know that conditions are going to change in a few weeks' or months' time, in such a way as to affect the direction of the trend in a predictable fashion.
Examples of this kind of situation are when you know that a particular new project is going to be rolled out onto the server in question, or that the number of users is going to increase suddenly, or that the server is going to be upgraded.
In these circumstances, it is extremely useful to be able to apply a specific change to the nature of the trend at a future date.
For example, you may want to specify that the slope of the trend is going to increase by a known proportion of its value at that time. This kind of change can be expressed as a "What-If". In the case where an automatic trend line has had a What-If change specified, you want this change to be honoured the next time the chart and its trend is automatically updated.
This shows an example of a What-If change specified to the trend on a particular chart.
It shows the trend suddenly turning upwards at a particular date, perhaps because the implementation of a new project will cause a greater rate of increase in the server workload. As a result, the value of 70% is predicted to occur earlier than originally thought, in fact on 15th May rather than 17th June, as was the case for the trend without the specified change.
Again, if the chart is automatically updated with data for another month, the trend is recalculated, and the existing What-If is automatically applied to the revised trend. This gives a new projected date for the 70% utilisation level.
Clearly, the ability to create and modify trends automatically gives significant added value to the charts, and to the reports that they will be embedded in.
In the conclusion to my blog series I’ll be looking at adding value to your reports with automatic interpretation on Wednesday.
Chief Marketing Officer
Chief Marketing Officer