121 lines
7.0 KiB
HTML
121 lines
7.0 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
|
<html>
|
|
<head>
|
|
<META http-equiv="Content-Type" content="text/html; charset=utf-8">
|
|
<LINK rel="stylesheet" type="text/css" href="../../../rzahg/ic.css">
|
|
|
|
<title>Java cache for user classloaders</title>
|
|
</head>
|
|
|
|
<BODY>
|
|
<!-- Java sync-link -->
|
|
<SCRIPT LANGUAGE="Javascript" SRC="../../../rzahg/synch.js" TYPE="text/javascript"></SCRIPT>
|
|
|
|
<h5><A NAME="clscache">Java cache for user classloaders</A></h5>
|
|
<p>The i5/OS Java Virtual Machine user classloader cache is a feature that allows the Java Virtual Machine to "remember" classes that have been loaded with user classloaders. This feature improves the startup performance of classes loaded by user class loaders by allowing the JVAPGMs created by user classloaders to be cached for reuse, avoiding JVAPGM creation and bytecode verification during the initial class load. WebSphere components (servlets and JSPs) are loaded by user classloaders and can take advantage of this feature. </p>
|
|
|
|
<p>For most applications, the default WebSphere setup provides the best solution. You should only consider the techniques described here if you are experiencing performance problems in the following areas:</p>
|
|
<ul>
|
|
<li><strong>Application server startup</strong>
|
|
<br>Servlets configured to load at startup are loaded when the application server is started.
|
|
|
|
<p>Having a large number of these components, or complex components that access many classes in your application, makes application server startup time longer.</p></li>
|
|
|
|
<li><p><strong>Component runtime during first-touch</strong>
|
|
<br>These components are loaded the first time they are accessed after the application server is started:</p>
|
|
<ul>
|
|
<li>servlets that are not configured to load at startup</li>
|
|
<li>JSPs </li>
|
|
</ul>
|
|
<p>If these components are complex or access many classes in your application, your first-touch times of these components are longer.</p></li>
|
|
</ul>
|
|
|
|
<p>The user classloader cache improves performance in two ways:</p>
|
|
<ul>
|
|
<li>Avoiding bytecode verification
|
|
<br>If the class is already in the cache, bytecode verification isn't performed again.</li>
|
|
<li>Avoiding creation of JVAPGMs
|
|
<br>If the class is already in the cache, the existing JVAPGM is used. Since any optimization level can be stored in the cache, it is more practical to consider higher optimization levels than previously.</li>
|
|
</ul>
|
|
<p>Note in both cases the first time the class is loaded (for example before the cache is primed or after a class is changed), these functions are performed and the load is slower. Once the class is already in the cache, these functions are not performed, so subsequent loads are much quicker. There is no way to prime the cache with classes other than running your application.</p>
|
|
|
|
|
|
|
|
<p><strong>Using the User Classloader Cache</strong></p>
|
|
<p>To enable the user classloader cache, the Java system property <strong>os400.define.class.cache.file</strong> must be specified with a valid value. Other Java system properties may be optionally specified. Use the following Java system properties to enable and customize the user classloader cache:</p>
|
|
|
|
<ul>
|
|
<li><strong>os400.define.class.cache.file</strong>
|
|
<br>This property must be specified to enable the Java user classloader cache function. The value specifies the full path name of a valid JAR file that holds the Java Program objects (JVAPGMs). This JAR file must contain a valid JAR entry, but need have no other content beyond the single member required to make the JAR command function. Here are two ways to create a cache JAR file.
|
|
<ul>
|
|
<li>V5R1 PTF 5722JV1 SI02683 installs a suitable JAR file, /QIBM/ProdData/Java400/QDefineClassCache.jar. You may use this JAR file as is, or copy and rename as desired.</li>
|
|
<li>Create your own cache JAR file as follows:
|
|
<ol>
|
|
<li>Start Qshell by entering the command <tt>STRQSH</tt>.</li>
|
|
|
|
<li>Switch to the directory where you want the JAR file located. Make the directory first, if necessary.
|
|
<pre>
|
|
mkdir /cache
|
|
cd /cache
|
|
</pre></li>
|
|
|
|
<li>Create a dummy file to place in the JAR. The name can be anything, this example uses <tt>example</tt>.
|
|
<pre>
|
|
touch example
|
|
</pre></li>
|
|
|
|
<li>Build the JAR file. This example names the JAR file <tt>MyAppCache.jar</tt>
|
|
<pre>
|
|
jar -cf MyAppCache.jar example
|
|
</pre></li>
|
|
<li>Cleanup the dummy file
|
|
<pre>
|
|
rm example
|
|
</pre></li>
|
|
</ol>
|
|
<p>The value of the os400.define.class.cache.file property would be /cache/MyAppCache.jar.</p></li>
|
|
</ul>
|
|
|
|
<p>This JAR file must not be on any classpath.</p>
|
|
|
|
<p>DSPJVAPGM can be used on this JAR file to determine how many JVAPGMs are cached. The <tt>Java programs</tt> field of the DSPJVAPGM display indicates how many JVAPGMs are cached, and the <tt>Java program size</tt> 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.</p>
|
|
|
|
<p>CHGJVAPGM can be used on this 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 below.</p></li>
|
|
|
|
<li><p><strong>os400.define.class.cache.hours</strong>
|
|
<br>Specifies how long (in 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).</p></li>
|
|
|
|
<li><p><strong>os400.define.class.cache.maxpgms</strong>
|
|
<br>Specifies the maximum number of JVAPGMs the cache can hold. If this value is reached, the least recently used JVAPGMs is replaced first. The default value is 5000. The maximum value is 40000. </p></li>
|
|
</ul>
|
|
|
|
|
|
|
|
<p>Note that other Java system properties, such as os400.defineClass.optLevel, can be used to customize how JVAPGMs are created in the cache.</p>
|
|
|
|
|
|
|
|
|
|
<p>To add Java system properties to an application server, perform these steps:</p>
|
|
<ol>
|
|
|
|
<li>In the WebSphere administrative console click <strong>Servers --> Application Servers --> <em>server_name</em></strong>.</li>
|
|
<li>In the <strong>Additional properties</strong> section, click <strong>Process Definition</strong>.</li>
|
|
<li>In the <strong>Additional properties</strong> section, click <strong>Java Virtual machine</strong>.</li>
|
|
<li>In the <strong>Additional properties</strong> section, click <strong>Custom Properties</strong>.</li>
|
|
<li>Click <strong>New</strong> to add a property.</li>
|
|
</ol>
|
|
<p>For example, to use the shipped cache JAR with a maximum of 10,000 JVAPGMs that have a maximum life of 1 year, you would add the following:</p>
|
|
<table>
|
|
<tr><th>Property</th><th>Value</th></tr>
|
|
<tr><td>os400.define.class.cache.file</td><td>/QIBM/ProdData/Java400/QDefineClassCache.jar</td></tr>
|
|
<tr><td>os400.define.class.cache.hours</td><td>8760</td></tr>
|
|
<tr><td>os400.define.class.cache.maxpgms</td><td>10000</td></tr>
|
|
</table>
|
|
|
|
|
|
|
|
|
|
</body>
|
|
</html>
|