Summary for the WebSphere environment performance tests

Edit online

After performing performance tests on our WebSphere Application Server environment, we compiled a summary of our results and recommendations.

Our test results and recommendations are Trade specific. Parameters useful in our environment might be useful in other environments, but because caching benefits and costs are highly dependent on application usage and system configuration, you will need to determine what works best for your environment1. For our detailed test results information, refer to Results for the WebSphere environment performance tests.

The following are our summary results:
  • If the WebSphere® Application Server runs CPU constrained, the throughput and response times are significantly limited. If the monitoring methodology creates averages over a certain time span, this scenario might not be obvious at all times because it flattens the peaks. Because our two virtual CPUs were fully utilized, we also performed several tests with four virtual CPUs on the WebSphere Application Server. We saw higher throughput with four virtual CPUs. Also, the larger dynamic cache did not reduce the performance. See Varying virtual CPUs on the WebSphere Application Server for details.
  • For our tests, the UDB load was of particular interest for the "No cache" setting. In our single node tests, the UDB server was almost 70% utilized, so when we started our cluster testing, we added a second CPU. For all other scenarios, the single CPU for UDB was sufficient.
  • 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. See Varying Trade caching modes for details.
  • Caching benefits and costs are highly dependent on application usage and system configuration.
  • With a single WebSphere Application Server, the Trade caching option of DistributedMap gave the best results. Improvement compared with the No cache option was a factor of 2.7. See Varying Trade caching modes for details.
  • To use caching with the caching proxy, it was necessary to install the latest fixlevel, 6.0.2-13 (efix update provided by lnx.6.0.2.12.nlv.390.nogskit.tar.gz from ftp://edgecust:cust1serv@service2.boulder.ibm.com/edge/cp_without_gskit/6.0/) and to enable the socket pool on the caching proxy server. It is important to ensure that the socket pool is not too small as well as to select a suitable connections timeout setting. Be aware that because of the connection timeout, the sockets might be blocked longer than the user is connected. For our workload with 300 connected threads, setting the MaxSocketsPerServer parameter to 500 and the ServerConnTimeout parameter to 5 was suitable.
  • We found that a WebSphere Application Server dynamic cache size of 10,000 statements was best for all tests. When the WebSphere Application Server runs CPU constrained, a larger cache size reduced the throughput. See Varying WebSphere Application Server dynamic cache size for details.
  • The response time was linearly related to the number of clients. Most throughput improvements, for a certain number of clients, also reduced the response time. See Varying Trade clients for details.
  • For the guest LAN type HiperSockets™, a Maximum Frame Size (MFS) size of 24 KB could be recommended. The MFS size is specific for this workload with small requests. The WebSphere Load Balancer does not support HiperSockets. If a load balancer is needed, the guest LAN type must be Queued Direct I/O (QDIO). See Modifying the z/VM guest LAN type for details.
  • If no caching is used, the environment could see a throughput improvement of 70% using a four-node cluster (compared to a single WebSphere Application Server). See Varying WebSphere Application Server nodes without caching for details.
  • With no caching, a cluster of four WebSphere Application Servers, each with two virtual CPUs, was able to saturate the eight physical CPUs in the LPAR.
  • The CPU cost for the VM control program is shown by either the ratio of total to virtual CPU or the percentage of total elapsed time that the processor was charged to the system (control program time not attributed to specific users). For the total to virtual ratio we had an overhead from 11% to 17% for all CPUs. The system cost was about 1.5% on CPU0 and about 0.5% on each of the other seven CPUs.
  • In our tests we experienced no VM paging and there was no XSTOR utilization. This was expected because we had no memory overcommitment.

Benefits of using z/VM

There are many benefits of using z/VM in a Linux® on zSeries® environment. The following list shows how environments like ours could benefit from z/VM.
  • Using z/VM reduces administration effort
    • Systems can be easily cloned
  • Isolated networks can be easily implemented without hardware and cables
  • Easy administration of one physical system
  • The Performance Toolkit for z/VM provides a single point to easily monitor all servers
  • Using z/VM provides a very efficient use of the hardware
    • Sharing physical resources leads to efficient hardware use.
  • The homogeneous structure of the systems lead to homogeneous usage of hardware, which can be easily handled with less physical resources in a virtual environment, while a physical environment needs a component for each server. For example, one physical network card was sufficient to support our whole network load.
  • Using virtual CPUs allows consolidation of several low utilized systems on a small number of CPUs with high utilization, which reduces cost and overhead.
  • It is possible to use more virtual hardware than available physical hardware (over commitment).
  • z/VM can increase speed for data transfers
    • Because virtual LANs are used, the latency associated with a physical network is reduced and memory-to-memory data transfer rates could be achieved.
1 THE INFORMATION CONTAINED IN THIS DOCUMENTATION IS PROVIDED FOR INFORMATIONAL PURPOSES ONLY. WHILE EFFORTS WERE MADE TO VERIFY THE COMPLETENESS AND ACCURACY OF THE INFORMATION CONTAINED IN THIS DOCUMENTATION, IT IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. IN ADDITION, THIS INFORMATION IS BASED ON IBM'S CURRENT PRODUCT PLANS AND STRATEGY, WHICH ARE SUBJECT TO CHANGE BY IBM® WITHOUT NOTICE. IBM SHALL NOT BE RESPONSIBLE FOR ANY DAMAGES ARISING OUT OF THE USE OF, OR OTHERWISE RELATED TO, THIS DOCUMENTATION OR ANY OTHER DOCUMENTATION. NOTHING CONTAINED IN THIS DOCUMENTATION IS INTENDED TO, NOR SHALL HAVE THE EFFECT OF, CREATING ANY WARRANTIES OR REPRESENTATIONS FROM IBM (OR ITS SUPPLIERS OR LICENSORS), OR ALTERING THE TERMS AND CONDITIONS OF THE APPLICABLE LICENSE AGREEMENT GOVERNING THE USE OF IBM SOFTWARE.