Introduction

Edit online

This study measures performance and throughput for the WebSphere® Application Server (both 64-bit and 31-bit) on Linux® for IBM® System z® with Java™ 2 Platform, Enterprise Edition (J2EE) workloads.¹

There are many customer workloads based on Web applications, including those that use Web servers, J2EE-based middleware, and backend databases. For these tests, a workload that heavily exercises all the major J2EE components, but does not make heavy use of resources on the backend database, was chosen. Using this workload, various performance studies of IBM WebSphere 6.1.0.15 on Linux for IBM System z with a DB2® database using Java-based clients, including servlets and Java Server Pages (JSPs), were conducted.

The advantage of 64-bit WebSphere is its ability to make use of a much larger Java Virtual Machine (JVM) heap than the 31-bit version. In theory, a 64-bit machine can address up to 16 exabytes of storage, millions of times more than the physical memory typically found on most computers. Of the available memory dedicated to a Linux system, a JVM heap can occupy a large percentage of that memory, but not all of the memory. Even on a system that only runs WebSphere and Java, there are still memory requirements outside of the heap for thread-level program stack allocation.1

Objectives

The objective of these tests was to use a representative workload to test different WebSphere Application Server environments and settings for a Java-based application on Linux for IBM System z. The environment was three-tiered, consisting of:
  • Up to three J2EE clients
  • A WebSphere Application Server in 31-bit or 64-bit mode, both running on 64-bit Linux for IBM System z
  • An IBM DB2 Universal Database™ (UDB) on Linux for IBM System z
The objectives include:
  • Study JVM heap size in 64-bit mode.
  • Compare 64-bit versus 31-bit performance on WebSphere 6.1.0.
  • Study Central Processing Unit (CPU) scaling.
This information will help IT architects design and choose the correct size for middleware and database resources for Web-based J2EE applications that make heavy use of J2EE middleware components such as:
  • Servlets
  • Java Server Pages (JSPs)
  • Enterprise Java Beans (EJBs)
  • EJB Container Managed Persistence
  • Java Messaging Services (JMS)
  • Transactions
  • Database connections

Executive summary

This study explores the performance of a WebSphere Application Server 6.1 system under a customer-like J2EE application workload. This study includes a very detailed description of how the test environment was set up and how the systems were configured. The difference in performance behavior of the 31-bit and the 64-bit WebSphere versions was compared, and the impact of heap size and garbage collection was analyzed.

CPU scaling studies explored the maximum workloads using one, two, four, and eight Central Processing Units (CPUs) and showed a very good linear scaling, making it easy for a system administrator to plan the resources needed for scaling this workload.

Results show that with a special scenario at the highest workload level, which used eight CPUs, the 64-bit WebSphere version with a large heap produced the best results. With the high computing power of the IBM System z10™, the network bandwidth becomes a critical factor. At the highest workload submission rate (the rate that workload transactions are sent to WebSphere), a 10 Gb Ethernet card was needed to manage the traffic from the workload generating clients.

The results show also that the bandwidth of the interconnect between WebSphere and the database has a significant impact on performance. The HiperSockets™ connection under LPAR is a very appropriate connectivity type for this.

Summary

The IBM WebSphere Application Server helps drive business agility by providing developers and IT architects with an innovative, performance-based foundation to build, reuse, run, integrate, and manage Service Oriented Architecture (SOA) applications and services. IBM DB2 Universal Database (UDB) provides a database management system for mission-critical enterprise data. WebSphere as an interface to DB2 provides a means for the Web-enablement of data and business logic. WebSphere introduced support for 64-bit platforms early in Version 6, while continuing to provide a 31-bit WebSphere able to run in compatibility mode.

Java Virtual Machines (JVMs) in 64-bit mode have provided key advantages, including a significantly larger Java heap size, as well as Java code optimizations. The IBM System z 31-bit WebSphere provides a maximum heap size of approximately 1 GB, while the 64-bit WebSphere heap can address as much as 256 TB, far exceeding the available physical memory of the current platforms.

This study set up and used a system that provides a high throughput for a workload using all major J2EE components on the WebSphere Application Server. The characteristics of the workload used in this study are that throughput depends primarily on the submission rate selected when installing the workload. When sufficient resources are available to support a certain submission rate, more resources do not increase the throughput. The first indicators of processor over-utilization are increasing response times and increasing CPU utilization.

While there are advantages of running on a 64-bit JVM WebSphere, there are also disadvantages, including 8-byte pointers and a greater memory requirement overall. This study showed that 64-bit WebSphere could equal or exceed the performance of 31-bit WebSphere with a more conventional middleware-intensive workload. However, in some tests, 64-bit WebSphere showed a slightly degraded performance when compared to 31-bit WebSphere.

While throughput data from this workload is fairly identical across both architectures, Central Processing Unit (CPU) percent-busy statistics showed that 64-bit WebSphere is, in scenarios with high workloads, able to use its much larger heap size to provide efficiencies of scale at the higher workload submission rates.

At lower submission-rate workloads, 31-bit WebSphere still had a performance advantage in terms of shorter response times, because the number of stored objects (EJBs, JSPs) was smaller and fit comfortably in the 31-bit 1 GB (1024 MB) heap. Garbage collection durations were short, even if frequent. The comparison studies were prepared by first studying the optimal heap size for the 64-bit WebSphere JVM. It was found that for the workload used in this study, a Java heap size ranging between 70% and 75% of the system memory resulted in the best trade-off between maximum throughput, short response times, and low CPU utilization.

A CPU utilization rate greater than 90% was not observed for the higher workloads, indicating an unidentified bottleneck. This bottleneck might be the HiperSockets connection between the WebSphere Application Server and the database. Additional investigation would be required. The high CPU utilization rate of 97% for the run with one CPU on 64-bit WebSphere becomes a critical threshold for a system running with HiperSockets. This high utilization is very likely the reason for the high response times observed on the run with one CPU.

The CPU load of the DB2 LPAR is generally quite light for the transaction workload. A full CPU is rarely used unless there are already eight CPUs used on the WebSphere system. The workload generally uses short data records and does not use complex SQL statements, so the backend database load is expected to be light. The higher cost on the 64-bit WebSphere at a submission rate of 110 strongly suggests that the WebSphere CPU load is too high for the HiperSockets connection, because missing CPU resources on the middleware will cause overhead on the database.

The workload also shows good linear scaling until the highest workload. At the highest workload, throughput declines, falling away from a linear relationship. Here, the 64-bit version performs better than the 31-bit version. The poor response times at the highest workload are an indication of resource contention. It is assumed that the critical resource here is again the interconnect to the database. The database shows a decline in throughput and CPU at a fixed ratio (that is, the CPU cost per transaction stays the same), indicating that the database waits to receive requests from the application sever. Because there is no contention for CPU, this strongly suggests that the interconnect is the cause of the bottleneck.

The high response times with the workload submission rate of 600 in LPAR mode could be easily attributed to network I/O traffic from the clients reaching the limit of the 1 Gb Ethernet from the WebSphere system being tested. In this study, the limiting factor was the amount of packages, where the number of 80 000 packages could be considered as close to the upper limits of a 1 Gb Ethernet interface or card. Using a 10 Gb Ethernet card improved that situation.

1 This paper is intended to provide information regarding performance of environments using WebSphere Application Server 6.1. It discusses findings based on configurations that were created and tested under laboratory conditions. These findings may not be realized in all customer environments, and implementation in such environments may require additional steps, configurations, and performance analysis. The information herein is provided 'AS IS' with no warranties, express or implied. This information does not constitute a specification or form part of the warranty for any IBM products.