Non-SSL page access through a TCP junction, unauthenticated
In this test case the client accesses the Web page on the back end WebSphere® Application Server, unauthenticated via an unencrypted connection (TCP junction).
Using a page size of 5.8 KB
Figure 2 shows the CPU utilization of the z/VM® and z/OS® LPARs in a curve and the details of the z/VM guests as stacked bars. Guests with a utilization of nearly zero, like the Tivoli® Access Manager server, do not appear.
Observations
- The CPU utilization of the Firewall 1 system, the system with the Tivoli Access Manager and LDAP servers, and of the DB2® UDB server is very low.
- Scalability was good with 1.9 for 8 clients and 1.8 for 10 clients.
- The CPU utilization on the WebSEAL server seemed to be a major bottleneck, even though it was only 85% utilized.
- Increasing the number of clients with two CPUs resulted in a throughput improvement of about 9%.
- The CPU load on the other related systems (firewalls, DB2 UDB, Tivoli Access Manager / IBM® Tivoli Directory Service server) was very low.
Conclusion
The most critical resource was the CPU at the WebSEAL server. Just increasing the number of CPUs from one to two increased the throughput by nearly a factor of two without increasing the number of workload generators. The CPU load of the other servers needed from the WebSEAL server was very low, making this is an ideal environment to host on z/VM. For details on logging see Effects of WebSEAL logging on throughput.
Effects of WebSEAL logging on throughput
This test is a repeat of the scenario one test except that it is being used to compare the effect of WebSEAL logging. We reran the scenario one test with the WebSEAL logs assigned to files and with the logs assigned to /dev/null. These tests were done with WebSEAL's guest machine assigned two CPUs.
Observations
Logging to /dev/null improves the throughput, where the improvement for eight clients is 4.3% and for ten clients is 5.1%
Conclusion
The log file is a resource where the access is serialized. This is a bottleneck whose impact increases with the number of workload generators. This shows that the I/O bandwidth for the log file is another constraint besides CPU capacity. To ensure the maximum I/O bandwidth, it is recommended to place the log file at least on a separate disk to avoid the sequential I/O flow being interrupted by other I/O requests or use a logical volume striped over disks from several ranks, which is the better option.
Be aware that all our measurements using logging to a file suffered from this constraint.