Tuning Java virtual Machine

WebSphere application server is a Java based server and requires a Java virtual machine to run the server and applications deployed on it. Tunning underlying Java virtual machine can play a major role in tuning performance. The WebSphere Application Server runs on different JVMS. In most of the cases it is IBM JDK, but on Solaris it is Sun JDK,.. What parameters you can use and the syntax to set there values depends on the type of JVM your tuning.

The parameters that can be used for tuning JVM can be divided into following three types and you can tune all three of them from WAS Admin Console this page

Java memory or heap tuning: Java memory or heap controls the amount of memory that is allocated for use by individual application server instance. You can change the JVM both initial and maximum heap size. Increasing this parameter increases the memory available to the application server, and reduces the frequency of garbage collection. Increasing this setting can improve server response time and throughput. However, increasing this setting also increases the duration of a garbage collection when it does occur. This setting should never be increased above the system memory available for the application server instance. Increasing the setting above the available system memory can cause system paging and a significant decrease in performance. Tuning value of initial heap size reduces the overhead of garbage collection, which improves server response time and throughput. You can change the initial or maximum heap size by changing value of "Initial heap size" and "Maximum heap size" fields.

Garbage collection tuning: When the JVM cannot allocate an object from the current heap because of lack of contiguous space, the garbage collector is invoked to reclaim memory from Java objects that are no longer being used. Each JVM vendor provides unique garbage collector policies and tuning parameters. You can set the garbage collection policy by passing it as command line parameter using -X option suitable for your JVM. The generational garbage collection is the best performing garbage collection policy, Also by default, the JVM unloads a class from memory whenever there are no live instances of that class left. Class unloading can degrade performance. Turning off class garbage collection eliminates the overhead of loading and unloading the same class multiple times.

Start up versus runtime performance optimization: In some environments, such as development environment, it is more important to optimize the startup performance of your application server rathar than the runtime performance. In production or test environment it is more important to optimize the runtime performance than startup performance.The Java JIT compiler has a big impact on whether startup or runtime performance is optimized. The initial optimization level that the compiler uses influences the length of time it takes to compile a class method, and the length of time it takes to start the server. For faster startups, you should reduce the initial optimization level that the compiler uses. However if you reduce the initial optimization level, the runtime performance of your applications might be degraded because the class methods are now compiled at a lower optimization level. The share classes option of the IBM Java 2 Runtime Environment (J2RE) Version 1.5.0 lets you share classes in a cache. Sharing classes in a cache can improve startup time and reduce memory footprint. Processes, such as application servers, node agents, and deployment managers, can use the share classes option.