Scaling virtual CPUs on the webApp.secure guests
In these tests, virtual CPUs on the webApp.secure guest machine were increased from one to two to four. We also increased the number of physical CPUs on the z/VM® LPAR to keep the environment around the webApp.secure server constant. However, we did not test with six CPUs because of the significant amount of unused CPU capacity with five CPUs.
The following table shows how the virtual CPUs from the webApp.secure guest and the physical CPUs on the z/VM LPAR are scaled and also shows the number of clients used in this configuration.
| # of Virtual CPUs - webApp.secure | # of Physical CPUs - z/VM | # of Clients |
|---|---|---|
| 1 | 3 | 1 - 20 |
| 2 | 4 | 1 - 50 |
| 4 | 5 | 1 - 90 |
Throughput
Figure 1 shows the throughput scaling for one, two, and four virtual CPUs on the webApp.secure server.
Observations: With each number of virtual CPUs, throughput reaches a saturation point and stays stable even as the client requests are increased. The point of saturation scales with the number of CPUs.
CPU utilization
In this paper, the CPU utilization values are always normalized in a way that 100% means one CPU is fully utilized. The CPU utilization charts below (Figure 2 and Figure 3) show the utilization for each LPAR (z/VM or z/OS®) by a line with triangle symbols. The details of how the z/VM guests use the CPU is shown with stacked bars, which should sum up to the z/VM utilization without the operating system CP related CPU part, so it is always a little bit lower than the z/VM LPAR load. If the CPU load from a guest in the legend is not visible, that means it is too low to display.
The following figures show the CPU utilization in our environment, Figure 2 for two virtual CPUs and Figure 3 for four virtual CPUs.
Observations: When throughput saturation is reached, the CPU utilization on the webApp.secure server flattens. This happens even though the system is not fully utilized. The effort of the other systems in the DMZ (firewall, Web server) is less than a half CPU in all cases, which is very low. The two z/OS CPUs are utilized around a half and z/VM also has more than one CPU free.
Due to the short latency of the guest LAN and HiperSockets™ connection, the response times remained good, under 50 ms, even during the overloaded cases.
Conclusion: The systems in the DMZ are very well placed in the z/VM guest LAN because the alternative on other platforms require separate hardware boxes, which are never fully utilized, and a full network infrastructure with cables and a switch. You can achieve good response times using a HiperSockets connection and a z/VM guest LAN.