[devloperworks] 64-bit versus 32-bit JVM: Understanding performance implications for WebSphere Commerce sites

64-bit versus 32-bit JVM: Understanding performance implications for WebSphere Commerce sites

Introduction
IBM WebSphere Application Server comes in two flavors – 32-bit and 64-bit. More specifically, you have the option of using the 32-bit or the 64-bit Java Virtual Machine (JVM) with your WebSphere Application Server. Prior to Version 7 Fix Pack 1, IBM WebSphere Commerce supported only the 32-bit version of WebSphere Application Server. Starting with V7 FP1, WebSphere Commerce added support for 64-bit.
This article discusses the key difference between how the 32-bit and the 64-bit JVM utilize memory when serving a typical WebSphere Commerce workload. It also discusses how these JVMs compare in terms of their key performance characteristics – throughput, response time, and overall memory utilization. It concludes with a discussion on what you need to consider when moving to a 64-bit JVM and how this affects your planned deployments.

---

Back to top

Total memory equation in WebSphere Commerce deployments
WebSphere Commerce is a sophisticated application that creates many different types of Java objects. When a shopper enters a WebSphere Commerce site, he first interacts with JSPs, JSP fragments, and servlets. The JSPs invoke servlets, which in turn invoke session beans (EJBs) and databeans.
The session bean layer typically invokes controller commands, which invoke task commands. These task commands invoke entity beans (CMP EJBs). The entity beans execute SQL statements against the database, fetch result sets, and store relevant data in their properties.
Session beans, controller commands, and task commands execute business logic that uses Java variables, constants, objects, and collection classes to store transient data on the stack and in the JVM heap. These data are not persisted, but they have a footprint on the overall memory utilization of your site.
These objects fall into one of two categories:

• JVM-bound objects This category represents objects that cannot be cached externally to the WebSphere Commerce JVM and includes:
  
  • Session beans.
  • Entity beans.
  • Access beans.
  • Stack variables.
  • Transient business logic variables allocated on the heap.
  • Objects returned by external systems (for example, external search engines) for processing and displaying by WebSphere Commerce.
• Cacheable objects These objects can be cached externally to the WebSphere Commerce JVM by utilizing either the dynacache disk offload feature, edge caching, or WebSphere eXtreme Scale. These objects include:
  
  • JSPs.
  • JSP fragments.
  • Servlets.
  • Controller commands.
  • Task commands.
  • Java objects that extend the DistributedMap interface.
  • Contents of the WebSphere Commerce data cache.
  • Contents of the WebSphere Commerce marketing cache.

Note: At this stage, some of the JVM-bound objects can also be cached. For example, JDBC result sets are cached in the statement cache provided by the WebSphere Application Server connection pool. Entity beans are cached in the EJB cache. Know that these objects cannot be stored externally to the JVM. If the total memory space required by these objects is larger than what the JVM can provide, the site will experience a performance bottleneck.
If you take a snapshot of the WebSphere Commerce JVM heap, you see that JVM-bound objects typically do not take up more than 200 to 300 megabytes. The remainder of the JVM heap is occupied by cacheable objects that are retrieved and loaded into the JVM heap as needed. This difference between JVM-bound and cacheable objects is key to understanding performance between a 32-bit and a 64-bit JVM.

---

Back to top

The 64-bit JVM
WebSphere Commerce is a J2EE™ application that is deployed on WebSphere Application Server, which again comes in two editions: 32-bit and 64-bit. These two editions of WebSphere Application Server are identical in every way except one: they include different editions of the IBM J9 JVM (except on the Solaris™ platform, where they include different flavors of Sun's™ JVM).
The IBM J9 JVM comes in two editions: 32-bit and 64-bit. These two editions are identical to each other in every respect except one: how they address memory. The 32-bit edition has a limit on the maximum heap size that is addressed by the JVM. This limit varies by platform, but it is generally about 1.5 GB.
The 64-bit JVM can address a much larger heap size than the 32-bit JVM. Version 1.6 of the IBM J9 JVM introduced compressed references technology. Processing larger 64-bit references does come at a cost, and compressed references reduce this cost and make it more reasonable. The impact of compressed references is described in more detail later in the article. The concept is introduced here because it affects the maximum heap size addressed by the JVM.
With compressed references on (they are on by default), the IBM J9 JVM can address about 28 GB of memory. Without compressed references, the maximum heap size is unlimited.
One important caveat to keep in mind is that, currently, WebSphere Application Server does not provide in-version migration support for migrating from a 32-bit to a 64-bit JVM. If you start by deploying one edition of WebSphere Application Server and then decide to switch to the other, a re-installation is required. Because of this fact, it is important to understand the trade-offs between 32-bit and 64-bit performance, and make the right choice early in the project life cycle. The next section discusses how WebSphere Commerce performs on a 64-bit and a 32-bit JVM.

---

Back to top

Comparing 64-bit and 32-bit performance
How do you go about comparing 64-bit with 32-bit performance? For WebSphere Commerce, this comparison involves comparing the cost of using larger references to the cost of out-of-process memory access. This sounds complicated at first glance, but in the case of WebSphere Commerce, it is actually fairly straightforward.
Virtually all WebSphere Commerce sites make extensive use of caching. The typical size of a WebSphere Commerce cache is 5 to 6 gigabytes (GB). The 32-bit JVM can hold only about 1 GB of this in Java heap memory. WebSphere Application Server dynacache provides a feature called disk offload. This feature enables those cached objects that do not fit into the JVM heap to be offloaded to the disk. However, this does not mean that those objects have to be always retrieved from the disk. All operating systems supported by WebSphere Commerce provide a file-system cache capability.
When enabled and appropriately sized, the file system cache ensures that the disk offload file containing objects that do not fit into the JVM heap is also served out of RAM. Essentially, for a well-tuned WebSphere Commerce site, the trade-off between running a 64-bit versus 32-bit JVM involves in-process versus out-of-process memory access.
Comparing throughput characteristics
Before delving deeper into performance data, keep in mind that performance is based on measurements and projections using standard IBM benchmarks in a controlled environment. The actual throughput or performance for any user varies depending upon many factors, including the amount of customization, the I/O configuration of the system, the storage configuration, and the workload processed. Therefore, there is no assurance that an individual user will achieve results similar to those stated here.
To make a fair comparison of a 64-bit versus a 32-bit JVM throughput characteristics for a WebSphere Commerce workload, you need to consider the total size of the cache. As discussed above, the heap size of the running WebSphere Commerce JVM is largely occupied by cacheable objects. In the case of a 32-bit JVM, most of these cacheable objects that do not fit into the JVM heap need to be offloaded to disk, and end up in RAM via the file system cache. In the case of a 64-bit JVM, all cacheable objects can fit into a much larger heap size.
Figure 1 shows a throughput comparison for a 32-bit and a 64-bit JVM running a WebSphere Commerce workload. In this study, we varied the total size of the cache from 0 GB (no caching at all) to 10 GB. In all cases, the system had sufficient RAM to fully contain the file system cache, including the dynacache disk offload file. For each cache size, a step-up test was performed to establish the maximum possible throughput. In all cases, the 32-bit JVM slightly outperformed the 64-bit JVM. Although the compressed references technology available in the latest version of the 64-bit JVM has reduced the overhead of processing larger references, you still see a 5% to 15% penalty.

Figure 1. Throughput comparison for different WebSphere Commerce cache sizes

Effect of the file system cache
Figure 2 shows additional data points, comparing relative throughput performance for the 32-bit and 64-bit JVM. Look closely at the one showing throughput comparison for the large 30 GB total cache size. In this case, when we reduced the size of the file system cache available to the 32-bit JVM, its throughput performance declined significantly when compared to the 64-bit JVM.

Figure 2. Effect of the file system cache on 32-bit JVM throughput

Table 1 shows that the total memory footprint for the 32-bit system is about 7.9 GB. This is determined by adding the actual heap utilization and the size of the disk offload file. In the case of the 64-bit JVM, all of the memory utilized was in the Java heap, and the size of this heap was about 10 GB. As you can see, the 64-bit JVM running a typical WebSphere Commerce workload tends to utilize about 30% more memory than an equivalent 32-bit system running the same workload. The garbage collection overhead for the two systems tends to be about the same.
Memory footprint and garbage collection overhead
Table 1 compares the memory utilization and garbage collection (GC) overhead observed during one of our runs.

Table 1. Comparison of total memory utilization and garbage collection overhead

	32-bit	64-bit
Actual heap size	1.2 GB	~10 GB
Disk offload file Size	~6.7 GB	0
GC overhead	~8% (max 25%)	~9% (max 13%)

For the 32-bit system, the total memory footprint is determined by adding the actual heap utilization and the size of the disk offload file. In this case, it is about 7.9 GB. In the case of the 64-bit JVM, all of the memory utilized was in the Java heap. The size of this heap was about 10 GB. As you can see, the 64-bit JVM running a typical WebSphere Commerce workload tends to utilize about 30% more memory than an equivalent 32-bit system running the same workload. The garbage collection overhead for the two systems tends to be about the same.

---

Back to top

Moving to 64-bit
One of most frequently asked questions that we get from customers is: Now that WebSphere Commerce supports 64-bit, should I move to a 64-bit JVM? The answer is that this depends on a number of factors, and not all of them are strictly performance-related. Our lab testing indicates that a well-tuned 32-bit deployment still outperforms an equivalent 64-bit deployment. However, the 32-bit deployment requires more tuning to achieve this.
To achieve top performance from a 32-bit deployment, you need to be concerned with (among other tunings):

• JVM tuning.
• Dynacache disk offload settings.
• Size of disk offload files (one for each JVM deployed on the server).
• Efficiency of the file system cache (which varies on different platforms).
• I/O performance of disk that are used (typically a Storage Area Network).

In contrast to this, for the 64-bit deployment, you only need to make sure that you have sufficient RAM to hold the entire heap (including cached data) and tune the JVM. Tuning the 64-bit JVM requires the same steps and overall approach as the 32-bit JVM, except that key settings, such as the starting and maximum nursery size and starting and maximum heap size, all need to be proportionately larger.
Another important consideration is that not all heap size problems encountered by customers are necessarily related to the total size of cacheable objects that need to be contained. In some cases, the total size of non-cacheable, JVM-bound objects produced by for example, integration and customization, can become too large to fit into the 32-bit heap. In this case, the 64-bit JVM allows you to simply increase your heap size, potentially avoiding (or at least postponing) expensive code re-design and re-factoring exercises.

---

Back to top

Conclusion
For high-volume WebSphere Commerce customers who want top performance from their hardware, the 32-bit JVM is still the recommended choice. However, the 64-bit JVM is now fully supported by WebSphere Commerce, and it does provide a number of advantages:

• Reduced I/O traffic to a Storage Area Network (SAN).
• Simpler overall tuning.
• Greater flexibility when dealing with heap contention caused by an accumulation of JVM-bound objects.

For many customers, these benefits may be well worth the price of a fairly reasonable performance overhead associated with using the 64-bit JVM for WebSphere Commerce deployments.

Resources
Learn

• WebSphere Application Server V7 64-bit performance
  
  
• Top 10 64-bit IBM WebSphere Application Server FAQs (PDF)
  
  
• WebSphere Commerce V7 Information Center: JVM performance tuning (advantages of the 64-bit JVM)
  
  
• WebSphere Commerce V7 Information Center
  
  
• developerWorks WebSphere Commerce zone

Discuss

• WebSphere Commerce discussion forum

About the author

Mikhail Genkin is the Performance Architect for WebSphere Commerce. He has 15 years of software development experience and has contributed to many IBM products including WebSphere Commerce, WebSphere Process Server, WebSphere Integration Developer, Rational Application Developer, and Visual Age for Java-Enterprise Edition.