Introduction to the WebSphere environment performance tests

Objectives

The goal of the End-to-End Performance of a WebSphere Environment on Linux on zSeries Including Edge Components project was to produce a best practices paper describing the end-to-end performance of a WebSphere® Application Server cluster environment including firewall systems, Edge components like WebSphere Load Balancer and the caching proxy server, and the Web server.

The largest expansion was a four-node cluster. The network was split into three areas with different security levels - the unsecure external zone, the demilitarized zone (DMZ), and the trusted internal zone with the corresponding edge components. This is a typical setup for application servers providing services into the Internet. It protects the system with the application server and the data by suppressing direct access from the Internet completely and allowing only well controlled accesses via the proxy. The whole environment was setup with z/VM® guests on z/VM 5.2. Through the project, we gathered experience on how to analyze and tune a cluster environment on Linux® on IBM® System z™ using the Trade 6.0 (Trade) application. We also learned where some of the pitfalls can be found. We were trying to find the best configuration to achieve the highest throughput. The environment tested was a customer-like environment, not a high-end benchmark system. Our goal was to utilize a System z 8-way system offering a secure WebSphere Application Server environment using Edge components. We did not try to produce the fastest transaction rates possible with WebSphere Application Server. Using more IFLs, we could have achieved better scaling, but that was not our intent.

Executive summary

If the WebSphere Application Server runs CPU constrained, the throughput and response times are significantly limited and setup modifications can have a negative impact. Increasing the number of virtual CPUs for this system results in an improvement between 40% and 50% for the same scenario. This symptom is not obvious at all times. If the monitoring methodology creates averages over a certain time span, it flattens the peaks.

Enabling caching, either Command or DistributedMap, is highly recommended as long as data caching will not compromise data validity. We achieved the best results when using DistributedMap caching, which had a throughput 2.7 times higher than without caching. When enabling caching, take care to use an appropriate cache size for the WebSphere Application Server dynamic cache. The support for using caching must be provided by the application owner.

For guest LANs the connection type HiperSockets™ with an appropriate MFS size would produce the highest throughput. Unfortunately, the edge component Load Balancer does not support this connection type.

For guest LANs the connection type HiperSockets could be recommended, but an appropriate value for the Maximum File Size (MFS) size is required. Unfortunately, the edge component Load Balancer does not support this connection type.

A four-node cluster using no caching improves throughput by 70% compared to a single WebSphere Application Server limited by the full utilization of the eight physical CPUs of the LPAR. Using no caching creates a high CPU load on the DB2 Universal Database™ server, so the utilization of the database server also needs to be monitored for each cluster configuration.

The CPU cost for running under z/VM is shown by either the effort of the VM control program itself, which was about 0.6%, and the effort for a specific guest, which was between 11% and 17%. In our tests we experienced no VM paging and there was no XSTOR utilization. This was expected because we had no memory overcommitment.