Configuring managed asset and managed asset classloader cache sizes

Depending on the number of process applications that use managed assets and the number of files in the managed assets, you might experience slow performance when you work with managed assets. If the managed asset classloader cache, managed asset cache, or both caches are too small, the caches must be refreshed often, which decreases performance. Tune the caches by setting configuration parameters in the 100Custom.xml file to define cache sizes for managed assets.

About this task

Set the following configuration parameters to define the cache sizes for managed files. As the active snapshots and managed asset content increase, you might need to increase the cache sizes. If the cache sizes are set too small, thrashing can occur when managed assets are in use because the classloader objects frequently swap in and out of the cache. When thrashing occurs, you might see hung threads that show delays related to the ManagedAssetClassLoader code.

Note: Avoid using duplicate classes within the managed assets for a snapshot as you cannot control which class loads.

<classloader-cache-size>

Each snapshot of a process application or toolkit contains one classloader instance. Ensure that the <classloader-cache-size> is set to a value higher than the total number of active process application and toolkit snapshots.

<classloader-resource-map-size>

The <classloader-resource-map-size> parameter specifies the number of Java classes that managed assets can contain and cache across all snapshots. The size must be large enough to hold all the files from all the managed asset JAR files in your snapshots in the deployment environment. When multiple snapshots include the same set of managed asset JAR files, you must count the file contents multiple times. When a toolkit snapshot contains managed assets, you must count the file contents only once regardless of how many process application or toolkits refer to it. Include a buffer in the cache size you set so that it does not exceed the limit with further application development. The following example shows how to calculate the required cache size.

Consider that you have the following list of managed asset JAR files across all the snapshots in use:

file1.jar containing 50 class files
file2.jar containing 70 class files
file3.jar containing 100 class files

If you use a reserve of 20%, set <classloader-resource-map-size> to (50 + 70 + 100) * 1.2 = 264.

The following XML snippet shows the default values of these properties. You can use this snippet in the 100Custom.xml to configure the caches.

<server>
    <classloader-cache-size merge="replace">1000</classloader-cache-size>
    <classloader-resource-map-size merge="replace">5120</classloader-resource-map-size>
</server>

For more information about making changes to 100Custom.xml, see The 100Custom.xml file and configuration.

You can use the following methods to calculate the memory requirements for the managed asset cache and managed asset classloader cache. If the sizes of these caches cause memory issues for your application cluster members, you might need to increase the Java heap size.

For each file in the managed asset JAR file, the memory that is used by the managed asset caches is the sum of two lists. One list contains the asset and the other list contains an internal representation. The lists are of type java.util.LinkedList, which takes a key and a value. The key consists of a UUID and the path within the JAR file. The UUID is always 36 bytes, but the path length and therefore the size might vary. This key is used by both lists.

The first list holds the entire file content as the value. You must extract the file from the JAR file and check the file size. The internal representation that the second list holds is always 52 bytes. The memory usage for a file can be represented as follows:

2 x (UUID + path length) + file content + internal representation

By replacing the fixed values, the following formula can be determined:

2 x ( 36 bytes + path length) + file content + 52 bytes

For example, consider a JAR file that includes the following files:

* com/test/EchoService.class * com/test/EchoService.java, * META-INF/MANIFEST.MF * .classpath * .project

Although all of these files will be loaded, consider the com/test/EchoService.class for now. The sizes of the two lists are:

First list
- Key = (e9771549-3ff8-4d81-b678-f5dfee1b1b12, com/test/EchoService.class) = 36 bytes
- Path length = 26 bytes
- Value = file content of com/test/EchoService.class = 931 bytes
Second list
- Key = (e9771549-3ff8-4d81-b678-f5dfee1b1b12, com/test/EchoService.class) = 36 bytes
- Path length = 26 bytes
- Value = "managedasset:61.f9b29441-0b1a-4f03-adfd-e98120b3c435" = 52 bytes

The total bytes allocated for one file in the JAR file is 1107 bytes. To determine the exact memory usage of the JAR file, you must calculate the memory usage for each file in the JAR.

The size and path structure of a JAR file affects memory usage. When you package your JAR files, keep the following considerations in mind:

When you use a managed asset, the entire JAR file is loaded, including each file that it contains. To reduce the amount of data that is loaded, remove unnecessary files from the JAR file. Managed assets are loaded in Lazy mode. When you try to access one class in a JAR file, the entire JAR file is loaded.
Memory usage depends on the file sizes and path lengths. Thousands of small files in a deep package structure might have a significant impact on memory usage.