23 April 2014
Introduction
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.
Trademarks
Page 1 of 7
developerWorks
ibm.com/developerWorks/
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.
Page 2 of 7
ibm.com/developerWorks/
developerWorks
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.
Page 3 of 7
developerWorks
ibm.com/developerWorks/
<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.
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:
Tuning branch and snapshot cache sizes in IBM Business
Process Manager
Page 4 of 7
ibm.com/developerWorks/
developerWorks
ON lsw_po_versions (PO_TYPE,BRANCH_ID,START_SEQ_NUM,END_SEQ_NUM,PO_VERSION_ID)
ON lsw_po_versions (BRANCH_ID,END_SEQ_NUM) COMPUTE STATISTICS;
ON lsw_po_versions (BRANCH_ID,START_SEQ_NUM,END_SEQ_NUM) COMPUTE STATISTICS;
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.
Page 5 of 7
developerWorks
ibm.com/developerWorks/
Resources
IBM Business Process Manager V8.0 Information Center: The 99Local.xml and
100Custom.xml configuration files
IBM Business Process Manager V8.5 Information Center: The 99Local.xml and
100Custom.xml configuration files
developerWorks blog: Five things to know about IBM BPM performance tuning
IBM Redbook: IBM BPM V8.0 Performance Tuning and Best Practices
developerWorks BPM zone
Page 6 of 7
ibm.com/developerWorks/
developerWorks
John Stephenson
John Stephenson is a Senior Development Leader within IBM Business Process
Manager. Since 2006, he has worked on WebSphere Business Modeler Publishing
Server, Business Space powered by WebSphere, WebSphere Business Compass,
and IBM Business Process Manager.
Val Ciontu
Val Ciontu is a Software Developer with the IBM Business Process Manager team.
Dejan Krzelj
Dejan Krzelj is a Software Developer with the IBM Business Process Manager team.
Since 2004, he has worked on IBM Tivoli Provisioning Manager, IBM Tivoli Intelligent
Orchestrator, IBM Tivoli Provisioning Manager for OS Deployment, and IBM Business
Process Manager.
Copyright IBM Corporation 2014
(www.ibm.com/legal/copytrade.shtml)
Trademarks
(www.ibm.com/developerworks/ibm/trademarks/)
Page 7 of 7