Summary for the webApp.secure performance tests

Edit online

After performing performance tests on our webApp.secure test environment, we compiled a summary of our results and recommendations.

Our test results and recommendations are specific to our environment. Findings useful in our environment might not apply in other environments with other workloads. When reviewing our results, please keep in mind that the workload used for our testing is a very heavy workload and was intended to drive the system to its limits. Typical customer workloads might be much lighter. For our detailed test results information, see Results for the webApp.secure performance tests.

One virtual CPU on the webApp.secure server

  • When increasing the workload on the webApp.secure server the throughput increased quickly and reached a saturation point. At this point the CPU utilization on the webApp.secure goes to about 90% and limits the total throughput of the entire application system.
  • The other z/VM® guests were only lightly utilized, making the DMZ an ideal environment that could be efficiently hosted under z/VM.
  • The z/OS® system with the WebSphere® Application Server was also lightly utilized.

Multiple virtual CPUs on webApp.secure server and multiple physical CPUs on z/VM

  • When we increased the number of virtual CPUs on the webApp.secure server we also increased the number of physical CPUs on z/VM to cover the additional load.
  • When the workload exceeded the saturation point, the stable behavior was the same for one, two, and four virtual CPUs.
  • At throughout saturation, the firewall and Web server in the DMZ were only lightly utilized. This can indicate that hosting these systems under z/VM, on a z/VM guest LAN, is advantageous over platforms requiring separate hardware boxes, where these boxes would never be fully utilized and network latency is incurred.
  • With a z/VM guest LAN and HiperSockets™ connection, response times are good even in the case of transaction overload. This would be more difficult and costly to achieve in a hardware-implemented network.
  • At webApp.secure throughput saturation the z/OS LPAR CPU utilization was also light with two CPUs being only half utilized.
  • In all multiple physical CPU cases, z/VM had more than one CPU free. Reducing the number of physical CPUs on z/VM by one results in a moderate degradation of throughout, 5 - 10%, which is expected because of queuing effects. The cost of having one less CPU may make this an acceptable tradeoff.