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.
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.
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.
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.
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.
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
Discuss
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.
