VM Performance and Capacity Sizing Considerations

This is a list of considerations I put together after having a particularly bad month in terms of critical customer situations that could have been avoided or made more manageable. Many performance problems are really a matter of setting expectations too high or improperly. While I can appreciate that it is sometimes difficult to do sizings with 100% confidence, there are a few things that you can do to increase the chance of success.

1. Do the homework, don't rely on cheat sheets.

Do the homework, don't rely on cheat sheets. Anyone sizing processors with little more than a cheat sheet with a single column of numbers is asking for trouble. Use official sizing tools and z/VM Performance Reports.

2. Be specific when you define Performance

Be specific when you define Performance. Is it ITR, interactive response time, or elapsed times on batch jobs? How are you measuring that?

3. Be careful when inverting ITR and percentages.

Be careful when inverting ITRR and percentages. If the ITRR between processors A and B is 1.50, that means the throughput per processor second is 50% greater on B. It does NOT mean that processor B uses 50% of the processor for the same work. The inverse (1 / 1.50) is .67, not .50. Analogy: Car A gets 20 miles per gallon, Car B get 30 mpg. The MPGR (itrr) of A to B is 1.50 (30/20). So it would take 3 gallons to go 60 miles in Car A. In car B to go 60 miles it would take 2 gallons (or 33% less gas than it took in car A = (3-2)/3 ).

4. A faster processor may not lower processor utilization.

A faster processor may not lower processor utilization. This is a footnote to number 3. Do not expect the CPU utilization to go down just because you have a faster processor. More times than not, more work will occur. (example, if my compile use to take 1 minute and it now takes 10 seconds, it is unlikely that I'll sit around for 50 seconds before I issue my next command.)

5. Upgrading a resource which is not the bottleneck, will not make the bottleneck go away.

Upgrading a resource which is not the bottleneck, will not make the bottleneck go away. In some cases, it might even make it worse.

6. Removing one constraint will reveal another.

There is always a potential limit somewhere unless you have infinite resources. Removing one constraint will reveal another.

7. Collect appropriate performance data prior to making any change.

Collect appropriate performance data prior to making any change. This allows us to prove/disprove the performance change and help identify any changes in the workload. In some cases, you do not need to reduce the raw data; but at the very least it should be collected.

8. Use intelligent change management.

Use intelligent change management. Change as few things as possible at a time, and thoroughly document all changes. Change management is my friend.

9. Latent demand.

Latent demand. If a system bottlenecks on a resource and you remove that bottleneck, it is likely that additional work will get done. See number 4 above. Research was done years ago which showed as response time improved, think time decreased. Pretty wild stuff!

10. Do not substitute non-VM numbers when VM numbers are unavailable.

Do not substitute MVS or Linux or whatever numbers when VM numbers are unavailable. If you can not find a VM number, do not try fudging by using something else. While it can be valuable to know where other systems stand to get a worst or best case number, a blind substitution is dangerous.