Skip to main content

Why Everyone Should Capture Performance Baselines

Learn Dawn May's considerations and recommendations for performance baselines here

"i Can" in white against a purple banner with a grid of blue and green shapes

With most numerical data, a number requires a reference point for meaning, and performance data is filled with numbers. Baseline data provides reference points for numerical data and are essential for good performance management. A baseline is simply a collection of system performance metrics saved from a known point in time.

Baselines are useful to determine if a change has produced good or bad results. They are also very useful when unexpected performance issues occur as they can help guide subsequent investigation. 

Baseline Considerations and Recommendations

The first consideration is simply how many Collection Services collections you can keep online. The shipped default is 10 days of standard data, which is good, but more is better. A minimum of 15 days allows for comparison of up to two different weeks.  Ideally, I recommend 30 days if disk space allows. I also recommend setting your Collection Services collection interval to five minutes; five-minute intervals are vastly superior over 15-minute intervals when investigating problems.
 
Baseline data should be kept available so it’s easily accessible if or when needed. The best approach to saving baseline data is to create a separate library for these collections. Note that Collection Services file formats change by release, so keep data from prior releases in their own library. Copying older data into a different library prevents the system from expiring the data and the collections won’t be deleted. Use the CPYPFRCOL command to copy the performance collection to the different library. 
 
It's best to save the management collection objects when saving your baseline performance data, as the management collection object contains the full set of data. If you have enabled system monitor data, that data is also in the management collection object and you can create the performance data to include system monitor data as well. This allows for a granularity of one-minute intervals in the system monitor data. 
 
Performance collections should also be saved in case you can’t keep the data online. Saving performance data allows you to restore it if you have an issue that surfaces slowly over time; maybe you need to compare the performance signature from six months ago. I recommend saving the management collections objects; there is no need to save the standard data in the Db2 files.
 
I strongly recommend collecting and retaining baseline data from:
  • Known, good business days during core business hours
  • Key business timeframes most important to your business, such as day-, week-, month-, quarterly- or year-end processes
  • Collections prior to any type of change. Installation of PTFs, application updates, hardware upgrades, etc. You always want to be able to compare before-and-after signatures. These comparisons can be useful for troubleshooting, but also for demonstrating positive changes that improve the performance signature.
To conclude, let me share a story about the value of baselines. A client I worked with took my advice and saved their management collection objects. Many months later, an application started to experience performance issues. The known, good collection was restored to the system and we were able to compare the signatures. With this ability to compare good versus bad, we were able to identify key differences, which greatly helped in troubleshooting.
Webinars

Stay on top of all things tech!
View upcoming & on-demand webinars →