This topic only applies to application servers that are
enabled to use the i5/OS® Java™ Developer
Kit 6.0 Java virtual machine (JVM), which is also referred to as the
Classic JVM. Caching classes previously loaded by this user class
loaders for this JVM can reduce the amount of time that it takes to
load servlets, JavaServer Page (JSP) files and enterprise beans. Caching
classes is not required for most applications. However, in some situations,
caching classes improves how an application performs.
Before you begin
Verify that a specific application server is enabled to
use the Classic JVM. You can use either of the following techniques
to verify that the Classic JVM is enabled.
- Use the showVariables command of the AdminTask object to retrieve
JAVA_HOME for the node that is associated with the profile for a specific
application server. For example, if the server is located on the node
that is named myNode:
- Enter QShell
- Change the directory to by entering the command cd
profile_root/bin
- Issue the following command:
command wsadmin -conntype NONE -c '$AdminTask showVariables {-scope Node=myNode -variableName JAVA_HOME}'
- Verify that the ouput is /QIBM/ProdData/Java400/jdk6. This output
indicates that the Classic JVM is enabled.
- Run the dspwasinst script to . For example, to determine whether
servers in the default profile are enabled for this JVM:
- Enter QShell
- Invoke app_server_root/bin/dspwasinst
- Look for Java Virtual Machine name: Classic VM in
the output
About this task
Application server class loaders, application class loaders,
and application module class loaders load product components such
as servlets, JSP files and enterprise beans. These class loaders are
called user class loaders in the i5/OS documentation.
If
servlets, JSP files or enterprise beans in your application are slow
to load, a cache is available to improve the startup performance of
these components. The cache enables the i5/OS JVM to identify classes
previously loaded with user class loaders.
When the cache is
enabled, each Java program object (JVAPGM) created by a user class
loader is cached for reuse during the initial class loading. The first
time the class is loaded, the loading is slow because JVAPGMs are
created and bytecode is verified during the loading. After a class
is in the cache, JVAPGM creation and bytecode verification does not
occur, which makes subsequent loadings much quicker. You must run
your application to initially add the classes to the cache.
Table 1. Enabling the cache for certain components . Before attempting to enable the cache, determine whether using
the cache might enhance the performance of your components. You should
only enable the cache if your components are slow to load in the following
situations:
Your application contains these components |
The components load at this time |
Comments |
Servlets that are configured to load when an
application server starts or enterprise beans |
When the application server starts up |
Having a large number of these components, or
complex components that access many classes in your application, slows
application server startup. |
Servlets that are not configured to load when
an application server starts or JSP files |
When classes of the component are first accessed |
If these components are complex or access many
classes in your application, it takes longer to load these components
for the first time. |
To enable the user class loader cache, complete the following
steps.
Procedure
- In the administrative console, click server_name.
- Under Server Infrastructure, click process_name .
- Under Additional Properties, click .
- Specify os400.define.class.cache.file in
the Name field and the full path name of a valid Java archive (JAR)
file to hold the Java Program objects (JVAPGMs) in the Value field.
The os400.define.class.cache.file custom
property enables the Java user class loader cache. The JAR file specified
in the Value field must contain a valid JAR entry, but does not have
to have any other content beyond the single member required to make
the JAR command function.
The /QIBM/ProdData/Java400/QDefineClassCache.jar cache
JAR file is shipped with the product. You can use this JAR file as
is, or copy and rename it. You can also create your own cache JAR
file:
- Enter the STRQSH command to start the Qshell.
- Switch to the directory where you want the JAR file
located. Make the directory first, if necessary.
mkdir /cache cd /cache
- Create a dummy file to place in the JAR. Use
any name. This example uses example:
touch example
- Build the JAR file. This example names the
JAR file MyAppCache.jar:
jar -cf MyAppCache.jar example
- Clean up the dummy file:
rm example
This JAR file must not be on any classpath.
You can
use DSPJVAPGM on this JAR file to determine how many JVAPGMs are cached.
The field
of the DSPJVAPGM display indicates how many JVAPGMs are cached, and
the field
indicates how much storage is consumed by cached JVAPGMs. Other fields
of the display are meaningless when DSPJVAPGM is applied to a JAR
file used for caching.
Table 2. .define.class.cache.file
custom property . You can also use CHGJVAPGM on the JAR
file to change the optimization of the classes in the cache. CHGJVAPGM
only affects programs currently in the cache. Classes added to the
cache are optimized according to the other properties described in
this list.
Name |
Example value |
os400.define.class.cache.file |
/QIBM/ProdData/Java400/QDefineClassCache.jar |
- Click .
- Optional: Click again and specify one of the following custom properties
to customize the user class loader cache. Repeat this step
as many times as necessary to complete your customization.
- os400.define.class.cache.hours
- Optionally, specify the number of hours an unused JVAPGM persists
in the cache. When a JVAPGM has not been used and this timeout is
reached, the JVAPGM is removed from the cache. The default value is 168 (one
week). The maximum value is 9999 (about 59 weeks).
- os400.define.class.cache.maxpgms
- Optionally, specify the maximum number of JVAPGMs the cache can
hold. If this value is reached, the least recently used JVAPGMs are
replaced first. The default value is 5000. The
maximum value is 40000.
Table 3. .os400.define.class.cache.hours
and os400.define.class.cache.maxpgms custom properties . For example, to use the shipped cache JAR with a maximum of
10,000 JVAPGMs that have a maximum life of 1 year, add the specify
the following custom propertie:
Name |
Value |
os400.define.class.cache.hours |
8760 |
os400.define.class.cache.maxpgms |
10000 |
Other Java system properties, such as os400.defineClass.optLevel,
can be used to customize how JVAPGMs are created in the cache.
- Click and
then click to
save the configuration changes.
- Restart the application server.
Results
Classes will be cached after they are initially loaded by
the i5/OS Java virtual machine (JVM) user class loaders.