JVM performance tuning

For improved performance, JVM settings require careful tuning. Tune your JVM settings to avoid experiencing memory allocation errors. The symptoms for these errors can vary from intermittent performance problems to the periodic failure and restart of the JVM. Consider the default JVM settings set by WebSphere Commerce as a starting point. The information in the JVM performance tuning topic is specific to the IBM JDK.

Before you begin

Determine your caching strategy and configure your caches.
- Preparing to use caching in WebSphere Commerce
- Introduction to the Dynamic cache service
- Using cache monitor statistics to tune the dynamic cache service
- Mastering DynaCache in WebSphere Commerce Describes how to use WebSphere DynaCache to improve the performance of WebSphere Commerce websites.
- WebSphere Commerce High Availability and Performance SolutionsDescribes how to build a high performance and high availability Commerce site. Learn how to determine the correct capacity hardware to handle the workload and how to properly test code changes before you deploy in the production site.
Understand debugging techniques, and the diagnostic tools that are available to help you solve problems and improve performance in the IBM Virtual Machine for Java. For more information, see Java Diagnostics Guide 6.
Understand the Generational Concurrent Garbage Collector.

Tuning the Java virtual machine (JVM)

When a Java virtual machine (JVM) is started, it obtains a large area of memory from the underlying operating system. This area is called the heap, and Java performs its own memory management by allocating areas of the heap as memory is needed by the process.

Caching increases the complexity of memory tuning. To reduce complexity, tune memory in stages. First, turn off both WebSphere dynamic caching and the prepared statement cache; then, turn them on one at a time.

For an overview of initial configuration settings that affect performance and stability of a WebSphere Commerce environment see, Tuning the IBM virtual machine for Java. The values that are indicated for 32-bit JVM are the default JVM settings set by WebSphere Commerce. Adjust the values up or down, then determine the optimal values by measuring throughput, response times, and by analyzing log files to understand garbage collection overhead.

The Java heap parameter influences the behavior of garbage collection. Increasing the heap size supports more object creation. To set the maximum heap size, see Overview of WebSphere Commerce performance and stability configurations.

Use verbose garbage collection information to determine the amount of free memory in the heap. Generally, less than 40% free memory causes the garbage collection overhead to increase and performance to be negatively affected. To start, specify a maximum heap size -Xmx property value that provides about 45% free memory, and a minimum heap size -Xms property value of approximately 50% of the maximum heap size. Never specify a minimum heap size that is less than the maximum new area size (nursery size). Using Verbose Garbage Collection is one of most efficient ways to understand the memory utilization and the garbage collection behavior within the Java virtual machine (JVM). This feature adds detailed statements to the JVM error log file of the Application server about the amount of available and in-use memory. To set verbose garbage collection, see Enabling verbose garbage collection (verboseGC) in WebSphere Application Server.

Advantages of the 64-bit JVM

Starting with Feature Pack 1, WebSphere Commerce supports both the 32-bit and the 64-bit version of the WebSphere Application Server.

IBM recommends 64bit JVMs. The 64-bit JVM provides a number of advantages over the 32-bit JVM:

The 64-bit JVM gives you the ability to keep more cached data in the JVM heap. This capacity leads to less reliance on the DynaCache disk offload feature and, as a consequence, less I/O traffic to disk.
The ability to increase the maximum heap size beyond 1.5 GB is beneficial when the store is experiencing heap contention issues due to large number of non-cacheable application objects.

Note: WebSphere Commerce customers with highly tuned sites who are operating on a platform that has an effective file system cache capability (for example AIX or Linux) might observe lower total throughput. This is compared to the 32-bit JVM-based site.