Optimize the startup performance and the runtime performance
In some environments, it is more important to optimize the
startup performance of your WebSphere Application Server rather than
the runtime performance. In other environments, it is more important
to optimize the runtime performance. By default, IBM JVMs are optimized
for runtime performance while HotSpot based JVMs are optimized for
startup performance.
The Java JIT compiler has a big impact
on whether startup or runtime performance is optimized. The initial
optimization level used by the compiler 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 can reduce the initial
optimization level that the compiler uses. This means that the runtime
performance of your applications may be degraded because the class
methods are now compiled at a lower optimization level.
It
is hard to provide a specific runtime performance impact statement
because the compilers might recompile class methods during runtime
execution based upon the compiler's determination that recompiling
might provide better performance. Ultimately, the duration of the
application is a major influence on the amount of runtime degradation
that occurs. Short running applications have a higher probability
of having their methods recompiled. Long-running applications are
less likely to have their methods recompiled. The default settings
for IBM JVMs use a high optimization level for the initial compiles.
You can use the following IBM JVM option if you need to change this
behavior:
-Xquickstart
This setting influences
how the IBM JVM uses a lower optimization level for class method compiles,
which provides for faster server startups, at the expense of runtime
performance. If this parameter is not specified, the IBM JVM defaults
to starting with a high initial optimization level for compiles. This
setting provides faster runtime performance at the expense of slower
server starts.
Default: |
High initial compiler optimizations level |
Recommended: |
High initial compiler optimizations level |
Usage: |
-Xquickstart can provide faster server startup times. |
JVMs based on Sun’s Hotspot technology initially
compile class methods with a low optimization level. Use the following
JVM option to change this behavior:
-server
JVMs
based on Sun's Hotspot technology initially compile class methods
with a low optimization level. These JVMs use a simple complier and
an optimizing JIT compiler. Normally the simple JIT compiler is used.
However you can use this option to make the optimizing compiler the
one that is used. This change will significantly increases the performance
of the server but the server takes longer to warm up when the optimizing
compiler is used.
Default: |
Simple compiler |
Recommended: |
Optimizing compiler |
Usage: |
-server enables the optimizing compiler. |
Limit the number of dumps that are taken in specific situations.
In certain error conditions, multiple application server
threads might fail and the JVM requests a TDUMP for each of those
threads. This situation can cause a large number of TDUMPs to be
taken concurrently leading to other problems, such. as a shortage
of auxiliary storage. You can use the JAVA_DUMP_OPTS environment variable
to indicate the number of dumps that you want the JVM to produce in
certain situations. However it does not affect the number of TDUMPS
that are generated because of com.ibm.jvm.Dump.SystemDump() calls
from applications that are running on the application server.
For
example, if you specify the JAVA_DUMP_OPTS variable with the following
options, the JVM:
- Restricts the number of TDUMPs taken to one.
- Restrict the number of JAVADUMPs taken to a maximum of three.
- Does not capture any documentation if an INTERRUPT occurs.
JAVA_DUMP_OPTS=ONANYSIGNAL(JAVADUMP[3],SYSDUMP[1]),ONINTERRUPT(NONE)
See
the IBM Developer Kit Diagnostics Guide for more
information on using the JAVA_DUMP_OPTS environment variable.