IBM BPM performance tuning strategy part III

In the last blog we discussed application server level tuning for IBM BPM. In this part, we will focus on IBM BPM platform (or “TeamWorksConfiguration”) level performance tuning.

TeamWorksConfiguration

Many IBM BPM configuration settings are stored in xml files in the profiles directories. Values can be changed in 00Static.xml, but for some installations a preferable approach for upgrade safety is to make such modifications in 100Custom.xml to override the defaults.
These configuration files are read during server start so changes will require a server restart. The parsed output is written to the TeamworksConfiguration.running.xml file during server start. Therefore, to validate that your expected configuration changes actually are being used, confirm the value in this TeamworksConfiguration.running.xml file.

– kick-on-schedule

• The default value for “kick-on-schedule” is true.
• If kick-on-schedule is false, newly-scheduled tasks won’t be picked up until the next time the Event Manager polls lsw_em_task (up to the loader-long-period), which will increase latency, but will also increase overall throughput, by reducing the chatter and contention on the lsw_em_task table.
• For a system with heavily loaded Event Manager, this setting should be set to false.

– cached-objects-ttl

• This property defines the time in seconds. The default value is 0 second.
• This controls the version checks that occur against the TeamWorks Persistent Object cache. By default this is set to 0 meaning that any lookups from the cache are checked against the current version in the DB.
• We have found that this is a light weight call; however, in an environment where the objects should not be changing, such as production, you can increase this ttl setting and gain some performance improvement.
• Note that a non-zero value for this variable means when changes are made to your processes in production (including imports) you either need to wait the number of seconds that cached-objects-ttl is set to or you need to restart the process server before the system would be in a stable state.

– Disable notifications and automatic task list refreshes if they are not required

• • When running at high throughput rates, the overhead of processing notifications and automatic task list refreshes can become a Process Server scaling bottleneck. If notifications or automatic task list refreshes are not a business requirement, they can selectively be turned off on the Process Server.
  • To disable both notifications and automatic task list refreshes, set the following values in 100Custom.xml file. Disabling “web-messaging-push” will take care of disabling both notifications and automatic task list refreshes – In this case individual settings for NOTIFY_TASK_RESOURCE_ASSIGNED, NOTIFY_TASK_COLLABORATION_INVITE, NOTIFY_PROCESS_COMMENT_TAGGED, TASKLIST_TASK_RESOURCE_ASSIGNED and TASKLIST_TASK_FIELD_CHANGED will be ignored.

– bpd-queue-capacity

• • • This setting specifies the number of Event Manager Tasks that are loaded into memory for the business process definition (BPD) queue, which is an asynchronous queue that handles Event Manager Tasks that execute BPDs, timers, system tasks, and decision tasks.
    • According to the Red Book, “IBM Business Process Manager V8.0 Performance Tuning and Best Practices”, for optimizing the throughput and scaling, start with a bpd-queue-capacity of 10 per physical processor core (for example, 40 for a 4-processor core configuration), with a maximum value of 80. This is not an absolute limit, but consider the potential impact on Process Server memory utilization if the value is increased beyond 80.

– default-unversioned-po-cache-size & default-versioned-po-cache-size

• • • The default value for both the above properties is 500.
    • These configuration settings control the number of objects in the PO
    • For low volume environments with relatively few process applications and coaches, the default value may be sufficient. However, for more complex environments with many process applications or coaches, increase this value so that the process applications and coaches are held in the cache after their initial use. This step can improve response time when accessing these process applications and coaches. For example, increase each of these values to 1500.

For further information on “TeamWorksConfiguration”, please refer to the IBM Business Process Manager V8.0 Performance Tuning and Best Practices” red book at
http://www.redbooks.ibm.com/Redbooks.nsf/RedbookAbstracts/sg248216.html?Open

In next part of this blog, we will look at performance tuning at Process Application Level.