Caching classes previously loaded by the i5/OS Java virtual machine
(JVM) user class loaders 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 an application's performance.
Before you begin
Application server class loaders, application class loaders, and application
module class loaders load WebSphere Application Server 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.
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. |
- In the administrative console, click Servers > Application Servers
> server_name > Process Definition > Java Virtual Machine >
Custom Properties.
- Under Server Infrastructure, click Java and Process Management
> Process Definition > process_name > Java Virtual Machine.
- Under Additional Properties, click Custom Properties > New.
- 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 WebSphere Application Server. 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 Java programs field
of the DSPJVAPGM display indicates how many JVAPGMs are cached, and the Java
program size 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.
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 OK.
- Optional: Click New 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.
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 OK and then click Save to save the configuration
changes.
- Restart the application
server.