Anda di halaman 1dari 7

Tuning branch and snapshot cache sizes in IBM

Business Process Manager


Dave Booz (booz@us.ibm.com)
Senior Technical Staff Member
IBM

23 April 2014

John Stephenson (stephen@ca.ibm.com)


Senior Software Developer
IBM
Val Ciontu (vciontu@ca.ibm.com)
Software Developer
IBM
Dejan Krzelj (dkrzelj@ca.ibm.com)
Software Developer
IBM
IBM Business Process Manager Advanced, Standard, and Express maintain memory caches
that hold information stored in the IBM BPM database. This article shows how to effectively
tune two of these caches: branch and snapshot.

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.

Try the Workflow service


Create long-running, stateful workflows that orchestrate tasks and services with synchronous
or asynchronous event-driven interactions with the Workflow service from Bluemix. Try it for
free!

Copyright IBM Corporation 2014


Tuning branch and snapshot cache sizes in IBM Business
Process Manager

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.

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

Tuning branch and snapshot cache sizes in IBM Business


Process Manager

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.

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:

Tuning branch and snapshot cache sizes in IBM Business


Process Manager

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.

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:
Tuning branch and snapshot cache sizes in IBM Business
Process Manager

Page 4 of 7

ibm.com/developerWorks/

CREATE INDEX IDXA_PO_VERSIONS


COMPUTE STATISTICS;
CREATE INDEX IDXB_PO_VERSIONS
CREATE INDEX IDXC_PO_VERSIONS
CREATE INDEX IDXD_PO_VERSIONS

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.

Tuning branch and snapshot cache sizes in IBM Business


Process Manager

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

Tuning branch and snapshot cache sizes in IBM Business


Process Manager

Page 6 of 7

ibm.com/developerWorks/

developerWorks

About the authors


Dave Booz
Dave Booz is a Senior Technical Staff Member on the Business Process
Management Architecture team and responsible for Process Center and Repository
architecture. He has 26 years of experience in the IT industry, from operating system
development through middleware architecture.

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/)

Tuning branch and snapshot cache sizes in IBM Business


Process Manager

Page 7 of 7

Anda mungkin juga menyukai