Test scenario 3: Varying the number of virtual CPUs for 200 guests

Edit online

A CPU scaling was also done for the 200 guest scenario with one JVM per guest. This test was done to verify that the recommendation for running WebSphere® with two virtual CPUs is valid in extreme scenarios, where the level of CPU overcommitment is very high.

Figure 1 show the effects of running the workload with 200 guests, but changing the number of virtual CPUs from 1 to 2 per guest.
Figure 1. Throughput and LPAR CPU load - 200 guests (Emulation = guest load)
Bar graph of the throughput and CPU load when running 200 guests with 1 JVM each. The x-axis is the number of virtual CPUs and the ratio of physical to virtual. The y-axis has two scales. The scale on the left is the throughput measured in page elements per second. The values range from 0 to 4000. The scale on the right is the CPU load measured in number of IFLs, and ranges from 0 to 16. There are two sets of bars, with each set consisting of three bars representing the throughput, LPAR load, and z/VM load due to emulation. The set of bars on the left represents one virtual CPU, and a ratio of 1:8.3 for the physical to virtual ratio. The throughput bar is at a value of approximately 3800. The LPAR load bar is at a value of approximately 11.8 IFLs. The z/VM load due to emulation bar is at a value of approximately 11 IFLs. The right set of bars represents two virtual CPUs and has a value of 1:16.7 for the physical to virtual ratio. The throughput bar has a value of approximately 3700. The LPAR load bar has a value of approximately 14 IFLs, and the z/VM due to emulation bar has a value of approximately 11 IFLs.
Observations
With 200 guests, the two virtual CPU case has a slightly lower throughput and a considerably higher LPAR CPU load. The LPAR CPU load increases by 2.3 IFLs, the emulation part increases only by 1.9 IFLs
Conclusions
The major contribution of the increase in CPU load still comes from the Linux® guest (Emulation). But the increase of the level of CPU overcommitment from 8.3:1 to 16.7:1 causes an expected increase in z/VM® effort to manage 400 virtual CPUs on 24 real CPUs. It is impressive to see that z/VM is able to handle such an excessively large number of virtual CPUs with such a low impact on total throughput.

This test also shows that the earlier finding, that the WebSphere guest runs better with two CPUs than with one for this workload, is no longer valid with these high levels of CPU overcommitment.