Comparing 64-bit WebSphere versus 31-bit WebSphere

Performance of 64-bit WebSphere

The workload stresses all of the major J2EE components in the middleware layer, but does not stress the database or client software layers. The intent was to explore how deploying on a WebSphere Application Server running the 64-bit JVM versus deploying on the 31-bit version affected performance. This workload uses most of the J2EE components, including some components that other applications are only beginning to exploit, such as message queues and the service oriented architecture (SOA). Here data points are used where expected CPU utilization would not be maximized as it was in the CPU scaling studies, so CPU usage is not a limiting resource.

Costs and advantages of using 64-bit WebSphere

Significant performance gains are expected in applications capable of taking advantage of 64-bit WebSphere features. For example, reducing database requests by leveraging a large heap space to cache database data can provide significant gains. However, there is also a disadvantage for 64-bit WebSphere applications. All address references are 64-bits wide, roughly double the size of address references in 31-bit deployments. This results in an increased memory footprint and can reduce hardware cache efficiency. Therefore, applications might actually see a performance loss. The 64-bit processors also provide hardware support for double-precision numbers and wider 64-bit integers.

Heapsize and other factors

As with other studies, a 75% heap size value is chosen for all variations of the 64-bit WebSphere test, and used the 1024 MB (1 GB) heap size variation of the 31-bit WebSphere test. For 31-bit WebSphere, a mapped_base kernel setting is used to reduce the kernel memory footprint and provide more space for the 1 GB heap to live inside the 2 GB 31-bit address space.

At a workload submission rate of 600, the response times were unacceptably long. Reports generated by the sar command show that the network traffic between the client systems and the WebSphere system was exceeding the capacity of the network card on the WebSphere Application Server LPAR. Therefore, the 1 Gb OSA card is replaced with a 10 Gb OSA card for the test cases with a workload submission rate of 600. The network issue is discussed in detail in Network study – 1 Gb Ethernet versus 10 Gb Ethernet.

Garbage collection

The -Xgcpolicy:gencon garbage collection option specifies a choice of either Split Heap or Generational Concurrent garbage collection mode. The heap is split into two areas: the tenured area for long-lived objects, and a nursery area, where new and recently used objects are stored. This garbage collection features a movement of longer-lived objects (ones that have survived between five and ten scavenger garbage collections) to the tenured heap. The global garbage collection is a garbage collection of the tenured area with the longest-lived objects. This global garbage collection is associated with pause times, during which objects managed by the JVM are held exclusively (locked) and not available to the application. The Generational Concurrent option was chosen for this workload due to the existence of very short-lived objects coexisting with longer-lived J2EE objects that survive beyond the transactional commit phase.

The tenured heap size is set with the -Xmo<sizeM> JVM option. For example, -Xmo768m defines a 768 MB tenured area. The remainder of the heap is then dedicated to a nursery area. The -Xmo2048m option was chosen for the tenured area on the 64-bit runs using 8 GB of memory. The option -Xmo768m was chosen for the 31-bit JVM because the total heap for the JVM is only 1024 MB. It is possible to increase the tenured area to an even larger size on 64-bit WebSphere, but at the value of 2048m for the tenured area, only one global garbage collection occurs during the 10 minute steady-state interval, and that frequency of tenured area maintenance is considered acceptable. For more information about these options, see Other Java Virtual Machine arguments.

Methodology

CPU utilization, workload throughput, and response times were measured during the steady-state phase with workload submission rates of 300, 500 and 600. For the 300 workload submission rate, four dedicated CPUs were assigned to the system being tested. For the 500 and 600 workload submission rates, eight dedicated CPUs were used. The DB2® image continued to run with four CPUs and 8 GBs of memory. The submission rates reflect a high but not fully-utilized CPU load.

CPU utilization, throughput, and response time measurements are summarized in Table 1 and displayed graphically in Figure 1 and Figure 2.

Observations

The same throughput is observed for 31-bit and 64 bit WebSphere Application Servers. Also, the CPU utilization is very similar. There is a difference in the response time, which is slightly slower on 64-bit WebSphere Application Servers, until the 600 submission rate test, and then the response time on 64-bit WebSphere Application Servers is slightly better than 31-bit WebSphere Application Servers.

The Java garbage collection statistics were added to show the effect of the larger heap sizes of 64-bit WebSphere on the total amount of time spent in garbage collection. More total time spent in garbage collection is observed on the 31-bit WebSphere than on the 64-bit version. On 31-bit, the average duration of garbage collection intervals is much shorter, but the frequency of garbage collection is much higher than on 64-bit. The total garbage collection time is used, which takes into account both garbage collection frequency and duration.

Using total garbage collection time, the time spent in garbage collection on 64-bit WebSphere was, approximately between 30% and 46% of the garbage collection time spent on the 31-bit version, significantly lower. At the highest workload submission rate of 600, the garbage collection time of the tenured heap area (Global garbage collection) was up to ten times longer on 31-bit WebSphere than on 64-bit WebSphere.

Conclusions

Under this workload, the behavior of the WebSphere Application Server is very similar for both 31-bit and 64-bit versions. With the larger workload, the 64-bit WebSphere Application Server has better response time, probably because garbage collection behaves differently. The -Xgcpolicy:gencon option was specified on the JVM command line for 64-bit WebSphere as well as the 31-bit WebSphere installation. The design of Generational Concurrent garbage collection is to minimize the time spent in global garbage collection of the tenured heap area by doing some concurrent cleanup of new object areas called nurseries.

Although pause times from exclusive locks held by global garbage collection are minimized by the JVM, they still consumed 9 seconds of total time on 31-bit WebSphere versus 1 second of total time on 64-bit WebSphere. This is one parameter that causes the slightly better response times observed on 64-bit WebSphere at the higher workloads with the larger 6 GB JVM heap. The larger tenured area (2048 MB versus 768 MB) on 64-bit WebSphere showed that fewer stop the world global garbage collections of the tenured area are needed on 64-bit WebSphere. Another reason for better response time is that the large nursery area afforded by the large 64-bit heap allows for the storage of more short-lived objects in memory for longer durations of time, resulting in fewer scavenger garbage collections and fewer memory allocation failures in the nursery area of the split heap.

These differences should result in improved performance on 64-bit WebSphere. However, this improvement is probably offset by the generally higher CPU requirements of 64-bit WebSphere observed for the workload.