Cache and cache-related settings

JavaScript engine

shared-scope-optimization-level
script-component-optimization-level
default-script-cache-optimization-level
coach-optimization-level
use-embeded-jscript-with-buff
cached-scope-size

The JavaScript engine configuration settings are used with JavaScript server-side script processing, but they can also be used to tune the performance of JavaScript code in Coaches. For those configuration settings that accept a numeric value between -1 and 9, a value of -1 means that the setting is interpreted, whereas a value from 0 to 9 specifies a level of optimization (with 9 being the level of most optimization with faster execution but slower compilation). A value of -1 is recommended and tests have demonstrated that any value other than -1 will generally hinder performance rather than help it.

The shared-scope-optimization-level setting specifies the optimization level for shared JavaScript code, such as the function library (which is loaded from process-server/resources/js). Large scripts can cause compilation failures. The default value is -1.

The script-component-optimization-level setting specifies the optimization level for script components in Teamworks services. Large scripts can cause compilation failures, which results in scripts being executed in interpretive mode. The default value is -1.

The default-script-cache-optimization-level setting specifies the default optimization level for most of the JavaScript code. This includes the JavaScript that is used for parameter mappings, UCA invocation components, integration components, exception handling components, etc. Generally, the JavaScript code is not large and should not cause compilation failures. In the event of compilation failures, scripts are executed in interpretive mode. The default value is -1.

The coach-optimization-level setting specifies the optimization level for the JavaScript code generated for coaches, including custom server-side JavaScript blocks that are inserted by authors (such as IBM BPM developers). Large generated scripts can cause compilation failures, which results in coach scripts being executed in interpretive mode. The default value is -1.

The use-embeded-jscript-with-buff setting specifies whether the EmbededJScriptWithBuff setting should be used everywhere instead of the deprecated EmbededJScript setting. The default value is true.

The cached-scope-size setting specifies the maximum size for the runtime scope cache. The default value is 50. If you set a value that is smaller than 5, your setting will be ignored and the default value will be used instead.

The JavaScript engine configuration settings are all located in the applicable 00Static.xml files, but updates to the default values of the settings must be made by adding the settings to the 100Custom.xml files.

<common>
   <javascript-engine>
      <shared-scope-optimization-level merge="replace">-1
      </shared-scope-optimization-level>
      <script-component-optimization-level merge="replace">-1
      </script-component-optimization-level>
      <default-script-cache-optimization-level merge="replace">-1
      </default-script-cache-optimization-level>
      <coach-optimization-level merge="replace">-1
      </coach-optimization-level>
      <use-embeded-jscript-with-buff merge="replace">true
      </use-embeded-jscript-with-buff>
      <cached-scope-size merge="replace">50
      </cached-scope-size>
   </javascript-engine>
</common>

ManagedAssetClassloader cache

classloader-cache-size
classloader-resource-map-size

Depending on the number of IBM BPM managed files and the number of process applications that use managed files, you might experience slow performance when you work with IBM BPM managed files. If the managed asset class loader cache, managed asset cache, or both caches are small, the cache must be refreshed often, which decreases performance. However, you can use the ManagedAssetClassloader settings to define the cache sizes for managed files.

The classloader-cache-size setting can be used to stop class loader instances from being swapped out of the cache too frequently. There is one class loader instance for each version of a process application. To prevent these instances from being swapped out of the cache too often, set the value to a number that is higher than the number of active process application versions on your system. For example, if you have n process applications and each process application has m active snapshots, set the value to (n*m). The default value is 1000.

The classloader-resource-map-size setting defines the number of Java classes that are inside managed files and cached over all process applications and versions. The default value is 5120.

The settings are located in the applicable 00Static.xml files, but updates to the default values of the settings must be made by adding the settings to the 100Custom.xml files.

Detailed information about the classloader-cache-size and classloader-resource-map-size settings is found in the topic Configuring managed asset and managed asset classloader cache sizes.

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

default-webapi-userid-cache-size

default-webapi-userid-cache-size

This setting has a default value of 500.

The setting is located in the applicable 00Static.xml files, but updates to the default value of the setting must be made in the 100Custom.xml files.

<common>
   <default-webapi-userid-cache-size merge="replace">500
   </default-webapi-userid-cache-size>
</common>

UserAttribute cache

cache-expiration-time
cache-max-size
query-performance-threshold

These three settings are UserAttribute cache settings.

The cache-expiration-time setting has a default value of 30000 milliseconds.

The cache-max-size setting has a default value of 200.

The query-performance-threshold setting has a default value of 3000.

The settings are all located in the applicable 00Static.xml files, but updates to the default values of the settings must be made by adding the settings to the 100Custom.xml files.

<server>
   <user-attributes>
      <cache-expiration-time merge="replace">30000
      </cache-expiration-time>
      <cache-max-size merge="replace">200
      </cache-max-size>
      <query-performance-threshold merge="replace">3000
      </query-performance-threshold>
   </user-attributes>
</server>   

team-task-user-cache-minutes-to-live

The team-task-user-cache-minutes-to-live setting specifies the cache life for user and team information used on dashboards. It has a default value of 15 minutes.

The setting is located in the applicable 98Local.xml files, but updates to the default value of the setting must be made by adding the setting to the 100Custom.xml files.

<server>
   <team-task-user-cache-minutes-to-live merge="replace">15
   </team-task-user-cache-minutes-to-live>
</server>

LRU cache

bpm-repo-max-cached-snapshots

This setting specifies the maximum number of cached snapshots in the BPM repository. The default value is 1000. The setting is located in the applicable 00Static.xml files, but updates to the default value of the setting must be made by adding the setting to the 100Custom.xml files.

<server>
   <repository>
      <bpm-repo-max-cached-snapshots merge="replace">1000
      </bpm-repo-max-cached-snapshots>
   </repository>
</server>

TWObject Class cache

twobject-class-cache-size

When a process or service accesses the value of a variable, it needs to load its business object definition. This lookup is initially performed in the snapshot of the running process or service and in its toolkit references. If a business object type has not yet been found, the lookup is performed from the process application snapshot in which the process instance was started. The TWObject Class cache remembers how a business object type is determined from a snapshot.

You can change the size of this cache with the twobject-class-cache-size setting in the 100Custom.xml files. The default value for the setting is 5000. Generally, the setting should be adjusted whenever you continuously see cache misses for TWClass in the Instrumentation monitor or logs.

An exact starting value is difficult to calculate because it requires deep knowledge about the process applications that run. You can start with a value of 5000 and then vary this value during performance tests.

If you have a deep understanding of the process applications, you can perform the following calculation for each process application snapshot to get a starting value:

(1 + N) * B

In this calculation, the variable N is the number of included toolkits that contain runnable artifacts (services or processes). (Those do not necessarily need to be exposed. If the same toolkit snapshot is used by multiple process applications, then it only needs to be included once in the calculation.) The variable B is the total number of business object types used within the process application. You can create a sum of the value for all process application snapshots and then use it as the starting value for the twobject-class-cache-size setting.

Although the setting is located in the applicable 00Static.xml files, updates to the default value of the setting must be made by adding the setting to the 100Custom.xml files.

<server>
   <twobject-class-cache-size merge="replace">5000
   </twobject-class-cache-size>
</server>

BusinessDataAliases cache

use-business-aliases-for-process-instances
bdac-refresh-interval
init-bdac-on-startup

Business process definition (BPD) variables that are configured to be available for search are assigned alias names and are cached in the business data alias cache. To improve performance, you can configure the cache to receive the business data aliases for only the snapshots that have associated instances, rather than keeping the default setting that returns all the aliases for all the snapshot definitions. You can use the BusinessDataAlias cache settings to configure the cache.

The use-business-aliases-for-process-instances setting impacts how the alias cache is loaded. You can build some saved searches from the complete list of aliases, and then switch to the instance-based list of aliases to get better performance. If the setting is set to its default value of false, all the BPDs are searched and the cache is loaded once with all the defined aliases in all the snapshots. If the setting is set to true, a list of searchable business data aliases is returned that is based on the aliases within existing BPD instances.

The bdac-refresh-interval setting specifies the interval between automatic cache refreshes. However, it is effective only when the value of the property use-business-aliases-for-process-instances is set to true. You might want to change the cache refresh interval when there are a small number of instances in the system or when instances start and are deleted before the cache is refreshed. This setting should have a shorter value in Process Center than in Process Server because Process Center tends to have fewer BPD instances running and the BPDs change much more frequently. The default value is 1800 seconds (30 minutes).

The init-bdac-on-startup setting controls when the cache is initially loaded. The setting is only effective when the use-business-aliases-for-process-instances setting is set to false. If the setting is set to the default value of true, the cache is initialized when the server starts. If the setting is set to false, the cache is initialized when it is first accessed, which generally means that the first user will experience a long delay.

The use-business-aliases-for-process-instances and init-bdac-on-startup settings are located in the applicable 99Local.xml files. The bdac-refresh-interval setting is located in the applicable 00Static.xml files. Updates to the default values of the settings must be made by adding the settings to the 100Custom.xml files.

Detailed information about the settings and how to set them in the 100Custom.xml files is found in the topic Business data alias cache configuration.

<server>
   <portal>
      <use-business-aliases-for-process-instances merge="replace">true
      </use-business-aliases-for-process-instances>
      <init-bdac-on-startup merge="replace">true
      </init-bdac-on-startup>
   </portal>
   <repository>
      <bdac-refresh-interval merge="replace">1800
      </bdac-refresh-interval>
   </repository>
</server>

Transformations

xsl-cache-max-size

This setting specifies the maximum XSLT cache size for teamworks.XSLConnector. The default value is 512. The setting is located in the applicable 99Local.xml files, but updates to the default value of the setting must be made by adding the setting to the 100Custom.xml files.

<server>
   <transformations>
      <xsl-cache-max-size merge="replace">512
      </xsl-cache-max-size>
   </transformations>
</server>

Service result cache

service-result-cache-size

This setting specifies the maximum size for the service result cache. The default value is 4096. The setting is located in the applicable 99Local.xml files, but updates to the default value of the setting must be made by adding the setting to the 100Custom.xml files.

<server>
   <service-result-cache-size merge="replace">4096
   </service-result-cache-size>
</server>

Task activity measures

max-cache-size
max-cache-entry-update-count
cache-entry-removal-policy

The max-cache-size setting has a default value of 100.

The max-cache-entry-update-count setting has a default value of 20. The value should be at least 1.

The cache-entry-removal-policy setting has a default value of Lru. The alternative value is Random.

The settings are located in the applicable 98Local.xml files, but updates to the default values of the settings must be made by adding the settings to the 100Custom.xml files.

<server>
   <task-activity-measures>
      <max-cache-size merge="replace">100
      </max-cache-size>
      <max-cache-entry-update-count merge="replace">20
      </max-cache-entry-update-count>
      <cache-entry-removal-policy merge="replace">Lru
      </cache-entry-removal-policy>
   </task-activity-measures>
</server>

task-authorization-invite-cache-size

This setting has a default value of 500. The setting is located in the applicable 98Local.xml files, but updates to the default value of the setting must be made by adding the setting to the 100Custom.xml files.

<server>
   <task-authorization-invite-cache-size merge="replace">500
   </task-authorization-invite-cache-size>
</server>

enable-process-instance-activity-tracking
cache-synchronization-interval

The enable-process-instance-activity-tracking setting specifies whether process tracking is enabled, which is used for obtaining process at-risk information for display in the Portal. If the setting is set to the default value of true, process tracking is enabled and the tracking daemon is started to synchronize tracking information from the database to the caches. If the setting is set to false, process tracking is disabled and the tracking daemon is not started.

The cache-synchronization-interval setting determines the interval of time between each run of the tracking daemon. The default interval value is 300 seconds.

Both settings are located in the applicable 99Local.xml files, but updates to the default values of the settings must be made by adding the settings to the 100Custom.xml files.

<server>
   <at-risk>
      <enable-process-instance-activity-tracking merge="replace">true
      </enable-process-instance-activity-tracking>
      <cache-synchronization-interval merge="replace">300
      </cache-synchronization-interval>
   </at-risk>
</server>

use-pre856-wsdl-cache
wsdl-cache-size

When you create an integration service in Process Designer, IBM BPM caches the files when the following conditions are true:

• Process Designer V8.5.6.0 was used to develop or update the integration service.
• During the development process, the web service configuration was specified by using the Discover Scheme step for WSDL discovery.
• The use-pre856-wsdl-cache setting is either not set or is set to false.

The use-pre856-wsdl-cache setting specifies whether the WSDL and XSD files from the web service provider are cached in the server memory before the integration service is initially called during each restart of the server. The default value is false. However, for migrated process applications, a value of true is generally specified.

The wsdl-cache-size setting specifies the number of WSDL files that are held in the cache. To balance memory cost and performance, you can use the setting to adjust the number of WSDL files in the cache. The default value is 25.

For additional information, see the topic WSDL and XSD cache algorithm for web service integration.

<common>
   <webservices>
      <use-pre856-wsdl-cache merge="replace">true
      </use-pre856-wsdl-cache>
   </webservices>
   <wsdl-cache-size merge="replace">25
   </wsdl-cache-size
</common>

cache-task-categories
category-cache-refresh-interval

The cache-task-categories setting applies specifically to the code that is used to populate the legacy Task Manager folder list (from TW5.0.x and earlier). It specifies whether Task Manager should use a single cached list of categories for all folders (where each folder contains the same list of categories). This setting has a default value of false. If a value of true is specified, the cache will be refreshed every 300 seconds (unless the default value of 300 seconds has been changed in the category-cache-refresh-interval setting). Otherwise, TeamWorks obtains the list of categories for each folder as usual. If you enable this setting, you will reduce database traffic and increase overall throughput. However, when the setting is enabled, certain categories may not appear until the cache refreshes and all categories will appear under each folder (even if no tasks in the folder are assigned to those categories).

The category-cache-refresh-interval setting specifies the number of seconds between each refresh of the category cache. The default value is 300 seconds (5 minutes).

The settings are located in the applicable 00Static.xml files, but updates to the default value of the setting must be made by adding the setting to the 100Custom.xml files.

<server>
   <cache-task-categories merge="replace">false
   </cache-task-categories>
   <category-cache-refresh-interval merge="replace">300
   </category-cache-refresh-interval>
</server>

unversioned-po-caching-enable

This setting is used to enable persistent object (PO) caching. The default value of true is recommended. The setting is located in the applicable 00Static.xml files, but updates to the default value of the setting must be made in the 100Custom.xml files.

<common>
   <unversioned-po-caching-enable merge="replace">true
   </unversioned-po-caching-enable>
</common>

Group member cache

group-member-cache-source

This setting specifies whether members of a group are only retrieved from the IBM Business Process Manager database and not from the user registry; for example, LDAP. This setting significantly increases the speed at which group members are loaded into the cache and it reduces the number of cache reloads. By default, the value is unset (null), but it can be set to the value DB in the 100Custom.xml file.

The system uses an in-memory group member cache to keep track of the members of a group. When the system is adding a group to a team, it retrieves the members of the group from both LDAP and the IBM BPM database. For large groups, LDAP access for retrieving group members can take many minutes, which can make the system appear to hang. If LDAP connection timeout values are not high enough, the connection might terminate without any data retrieval.

To help resolve this problem, add the group-member-cache-source setting to the 100Custom.xml files to specify that the members of a group are determined from the database only.

For more information, see the topic Specifying that members of a group member cache are retrieved from the database.

<server>
   <group-member-cache-source merge="replace">DB
   </group-member-cache-source>
</server>