Contents


Tuning branch and snapshot cache sizes in IBM Business Process Manager

Comments

IBM Business Process Manager (BPM) Advanced, Standard, and Express maintain memory caches that hold information that is stored in the IBM BPM database. Learn how to effectively tune two of these caches: the branch cache and the snapshot cache.

As IBM BPM process applications are developed, the changes that are made to versioned objects are tracked in the IBM BPM repository. Versioned objects consist of process models, service models, coaches, and so on. These objects are denoted by a three-part identifier: project, branch (or track), and snapshot. The project is represented as a process application or toolkit. Each project can have one or more branches (or tracks), where objects can evolve independently.

By default, each project has a single branch called main. On each branch, each object has a specific version that is created whenever the object is saved to the database. When a project is finished and is ready to move to the next phase of its lifecycle, a snapshot is created. When the snapshot captures all the objects at the current point in time, the snapshot is taken on the current branch in the current project.

When processes or services run in IBM BPM, the objects that make up the process application and its dependent toolkits are loaded into memory. In addition to the objects themselves, metadata about the branch and snapshot is also loaded and cached. All of this is loaded into the branch and snapshot caches, respectively.

Overview of the branch cache

One entry in the branch cache is used for each project-branch combination that is loaded into the memory cache. For example, if a process application depends on two toolkits, three branch cache entries are required: one for the process application and one for each toolkit. Each entry in the branch cache contains a snapshot cache. Therefore, the number of entries in the branch cache is tunable, independently from the snapshot cache.

Branch cache entries are reused across project dependencies in the same way that the objects are reused across project dependencies. For example, if a process application that has two snapshots deployed where both snapshots depend on the same two toolkit snapshots, the branch cache will have four entries: one for each process application snapshot and one for each toolkit snapshot. The same is true if two different process applications each have one snapshot deployed, where both snapshots depend on the same two toolkits: four branch cache entries are created.

The branch cache is a Least Recently Used (LRU) cache, meaning that the oldest entry is removed to make room for a new entry when the configured size of the cache is exceeded. If the working set of branches is limited by the cache size being too small, more cache misses will occur. These cache misses can cause a significant increase of database activity on the LSW_PO_VERSIONS table because artifacts must be loaded directly from the database when a cache miss occurs.

Branch cache entries can vary widely in the amount of memory that they use. This is due to the fact that a snapshot cache is contained in a branch cache entry, and the size of a snapshot cache is dependent on the application. For example, a toolkit with one business object takes less than 1 MB of memory for the branch cache entry and the snapshot cache. The IBM BPM Portal Process application uses about 11 MB of memory. The system data toolkit uses several hundred MB of memory. There is a difference in memory usage because of the complexity of the relationships between the artifacts in the project and the volume of artifacts in each project. Therefore, it is difficult to precisely predict the amount of additional memory that will be used when you are tuning the branch cache.

To determine a rough calculation of the memory usage, use the following equation:

(# of unique Process Application snapshots + # of unique toolkit snapshots) x size_constant

The size_constant is a value in megabytes. A conservative value would be 5 MB, representing the average size of a toolkit project. A more realistic number might be lower, such as 2 or 3 MB, but it can be much higher if the project contains a large number of complex artifacts.This calculation considers the size of the branch cache entries, plus the size of the snapshot cache in the branch cache entry to be accounted for in size_constant. A basic branch cache entry with an empty snapshot cache is less than 1 MB.

When considering a change to the branch cache size, the effect on the BPM JVM memory also has to be considered. The number you choose for size_constant requires careful consideration. The following examples illustrate the relationship between the branch cache size and BPM JVM memory.

In the first example, the process application depends on 70 toolkits. This process application will require 71 branch cache entries, which is greater than the default of 64. In this case, the branch cache size should be increased to avoid constant queries against the LSW_PO_VERSIONS table, which slows down the entire system. Note, however, that if this process application depends on 70 toolkits, then it is also likely that each toolkit does not contain a large number of artifacts. The reason for having many toolkits is to create very discrete packages of capability. Therefore, increasing the branch cache size will not have much impact on the memory requirements of the BPM JVMs.

In the second example, there are several process applications, where each application depends on different versions of about 10 very large toolkits. If each process application also has a few snapshots on the system, then the branch cache could be nearing its default size. In the worst case, three process applications, times 2 snapshots each, times 10 toolkits snapshots (each process app snapshot depends on a different toolkit version than every other process application snapshot) is 60 branch cache entries. The snapshot cache within each entry is consuming a lot of memory because the toolkits are large and complex. If a fourth process application is added to this system, not only the branch cache size would need to be increased, but there will also be a corresponding increase in JVM heap usage.

Tip: A tactical approach to monitoring cache activity in Process Server is to ensure that the SQL query response time on the LSW_PO_VERSIONS table does not suddenly degrade after you deploy a new process application snapshot.

Configuring the branch cache

You can configure the branch cache in the 100Custom.xml file. The size of the branch cache is denoted as the number of branch cache entries that can be held in the cache. Recall that this is directly related to the number of unique process application and toolkit snapshots that are deployed. The amount of additional memory used by increasing the size of the branch cache can be estimated using the formula shown in the preceding section. The default is 64 entries. Following is an example of how to configure the branch cache in the 100Custom.xml file:

<server merge="mergeChildren">
  <repository merge="mergeChildren">
    <branch-context-max-cache-size merge="replace">64</branch-context-max-cache-size>
  </repository>
</server>

For information about the location of the 100Custom.xml file, see "The 99Local.xml and 100Custom.xml configuration files" topic for version 8.0 or version 8.5.

Overview of the snapshot cache

As stated earlier, the snapshot cache is tuned independently from the branch cache. Each branch cache entry contains a snapshot cache. In a Process Server environment, each deployed snapshot is deployed to a unique branch. Therefore, in Process Server, the snapshot cache (which is part of each branch cache entry) contains only one entry.

In Process Center, all the snapshots on a branch use the same branch cache entry; therefore, the number of entries in the snapshot cache might be more than one. The number of entries that are needed depends on the number of snapshots that have been accessed. Snapshots are accessed when the snapshot is activated or when Process Designer users view artifacts, play back artifacts, or do both at a specific snapshot version. Therefore, tuning the snapshot cache size is necessary only for the Process Center server. The necessity to tune the snapshot cache is based on anticipated usage patterns.

Snapshot cache entries can be quite large because they depend on application content. It is not uncommon for snapshot cache entries to reach several hundred MBs. The size depends on the complexity and volume of the artifacts in a given snapshot.

Configuring the snapshot cache

You configure the snapshot cache in the 100Custom.xml file. The size of the snapshot cache is denoted as the number of snapshot cache entries that can be held in the cache. Recall that this is directly related to the number of unique process application and toolkit snapshots that are being accessed. In the following example, the default value is used:

<server merge="mergeChildren">
  <repository merge="mergeChildren">
    <snapshot-cache-size-per-branch merge="replace">64</snapshot-cache-size-per-branch>
  </repository>
</server>

For information about the location of the 100Custom.xml file, see "The 99Local.xml and 100Custom.xml configuration files" topic for version 8.0 or version 8.5.

Overview of indexes

The versioning system in IBM BPM depends on a correctly tuned database. In addition to properly tuning the branch cache, it is important to optimize the indexes on the LSW_PO_VERSIONS table. The following indexes improve performance on IBM BPM V7.5 and later:

CREATE INDEX IDXA_PO_VERSIONS ON lsw_po_versions (PO_TYPE,BRANCH_ID,START_SEQ_NUM,END_SEQ_NUM,PO_VERSION_ID) COMPUTE STATISTICS;
CREATE INDEX IDXB_PO_VERSIONS ON lsw_po_versions (BRANCH_ID,END_SEQ_NUM) COMPUTE STATISTICS;
CREATE INDEX IDXC_PO_VERSIONS ON lsw_po_versions (BRANCH_ID,START_SEQ_NUM,END_SEQ_NUM) COMPUTE STATISTICS;
CREATE INDEX IDXD_PO_VERSIONS ON lsw_po_versions (PO_VERSION_ID,PO_TYPE,BRANCH_ID,START_SEQ_NUM,END_SEQ_NUM)

Conclusion

This article showed how to tune the branch and snapshot caches to ensure that your IBM BPM system is operating at peak efficiency. It showed how to consider the effect on JVM heap memory. It also illustrated the relationship between IBM BPM applications and the caches as well as the relationship between the caches themselves.


Downloadable resources


Related topics


Comments

Sign in or register to add and subscribe to comments.

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Business process management
ArticleID=969213
ArticleTitle=Tuning branch and snapshot cache sizes in IBM Business Process Manager
publish-date=04232014