IBM BPM performance tuning strategy part II

In the Part 1 of this series we discussed on why IBM BPM Performance tuning strategy is important for any rollout. In this part we will get into the details of performance tuning for the IBM BPM platform.

Before we get into the details of performance tuning, it is important to note that the performance of the system is not dependent only on the application code and application server. The overall performance of the system includes many other areas like network latency, database server performance and hardware performance. It is best to get these areas fixed in the early stages of the tuning exercise before you start tuning at the application code and application server levels. Preferably, these should have been done during the installation of the production setup itself. However, it is advisable to check these areas and tune them during any major deployment. These are generally applicable to all enterprise class applications and network, database and system administrators are well aware of how to identify and fix issues in these areas.

It is important to minimize network latency across the topology (for example, between Process Portal and Process Server, and between Process Server and the Process Server databases).

Now let’s get into the details for the performance tuning areas for the IBM BPM platform. They include:

1. JVM Heap Settings
2. Connection Pool Settings
3. Thread Pool Settings
4. TeamworksConfiguration
5. Application Review and tuning

1. JVM Heap Settings

Get the JVM runtime report from the application server team. Analyze the JVM heap memory, free memory and used memory. If JVM heap is highly utilized, increase the value for JVM heap max size.

Depending on the type of the installation of IBM BPM, it may be required to change the JVM Heap settings for either 1 cluster member (eg. SingleClusterMember1) or 3 cluster members (eg. AppClusterMember1, MEClusterMember1 and SupClusterMember1).

Below are the parameters we need to focus on for each cluster member.

–Maximum Heap Size

• WAS console allows you to specify value in MB. If the value is not specified, the default value would be 256 MB.
• The maximum heap size must be lesser than physical memory. If the maximum heap size is greater than the physical memory (RAM), paging error may occur. This impacts the performance. While determining the maximum heap size, you should allow appropriate RAM for the operating system and in the case of a 3 member cluster, the total of the maximum heap size for all the three cluster members.
• WAS console allows you to specify value in MB. If the value is not specified, the default value would be 256 MB.
• The maximum heap size must be greater than or equal to the initial heap size.
• Maximizing the JVM heap size will reduce the frequency of garbage collection which will improve the performance.

–Initial Heap Size

• WAS console allows you to specify the value in MB. If the value is not specified, the default value would be 50 MB.
• The value must be less than or equal to the Maximum Heap size.

Below is the procedure to update the JVM Heap.

• Login to the Websphere Console Portal
• Expand Servers and click on “All Servers”
• On the right hand side, you will get a list of the cluster members (For single cluster topology, you will get only 1 cluster member. For three cluster topology, you will get 3 cluster members.)
• Click on the cluster member ( Say AppClusterMember1)
• Under “Server Infrastructure” section, click on “Process Definition”
• Click on “Java Virtual Machine” from the menu on the right hand side
• Examine “Initial Heap Size” & “Maximum Heap Size” values for the selected cluster and update the value as required.

2. Connection Pool Settings

For optimum performance of database-intensive applications, tune the JDBC Connection Pools managed by the Application Server. This section describes how to tune JDBC Connection Pools to improve performance.

There are 7 different properties we need to focus on while tuning the database connection pool.

–Connection Timeout

• Specifies the interval, in seconds, after which a connection request times out and a ConnectionWaitTimeoutException is thrown.
• This value indicates the number of seconds that a connection request waits when there are no connections available in the free pool and no new connections can be created. This usually occurs because the maximum value of connections in the particular connection pool has been reached.
• If the Connection timeout is set to 0, the pool manager waits as long as necessary until a connection becomes available. This happens when the application completes a transaction and returns a connection to the pool, or when the number of connections falls below the value of Maximum Connections, and a new physical connection is created.
• The default is 180 seconds. If the value is set to 0, the connection timeout period would be infinite which is not recommended.

–Maximum Connections

• Specifies the maximum number of physical connections that you can create in this pool. When this number is reached, no new physical connections are created.
• For better performance, set the value for the connection pool lower than the value for the maximum thread pool connections of the web container.
• If Maximum Connections is set to 0, an infinite number of physical connections are enabled, and the Connection timeout value is ignored.

–Minimum Connections

• Specifies the minimum number of physical connections to maintain.
• If the size of the connection pool is at or below the minimum connection pool size, the unused timeout thread does not discard physical connections. However, the pool does not create connections solely to ensure that the minimum connection pool size is maintained.

–Reap Time

• Specifies the interval, in seconds, between runs of the pool maintenance thread.
• The smaller the interval, the greater the accuracy. If the pool maintenance thread is enabled, set the Reap Time value less than the values of unused timeout and Aged timeout.
• When the pool maintenance thread runs, it discards any connections remaining unused for longer than the time value specified in Unused timeout, until it reaches the number of connections specified in Minimum Connections. The pool maintenance thread also discards any connections that remain active longer than the time value specified in Aged timeout.
• To disable the pool maintenance thread, set Reap Time to 0, or set both Unused timeout and Aged timeout to 0. The recommended way to disable the pool maintenance thread is to set Reap Time to 0, and Unused timeout and Aged timeout are ignored. However, if Unused Timeout and Aged Timeout are set to 0, the pool maintenance thread runs. Physical connections which timeout due to non-zero timeout values are discarded as well as those connections that reside in a used pool (or shared pool) because they have been held longer than the time interval set for Aged Timeout.
• Default is 180 seconds.

–Unused Timeout

• Specifies the interval in seconds after which an unused or idle connection is discarded.
• Set the Unused timeout value higher than the Reap timeout value for optimal performance.
• Set the Aged timeout value higher than the Reap timeout value for optimal performance.

–Aged Timeout

• Specifies the interval in seconds before a physical connection is discarded.
• Setting Aged timeout to 0 supports active physical connections remaining in the pool indefinitely. Set the Aged timeout value higher than the Reap timeout value for optimal performance.
• If you set a value for Aged timeout, connections with an expired age are discarded, regardless of the minimum pool size setting.

–Purge Policy

EntirePool

• • • All connections in the pool are marked stale. Any connection not in use is immediately closed.
    • When using this purge policy, there is a slight possibility that some connections in the pool are closed unnecessarily when they are not stale. However, this closure is a rare occurrence.
    • In most cases, a purge policy of EntirePool is the best choice.

FailingConnectionOnly

• • Only the connection that caused the stale connection exception is closed. Although this setting eliminates the possibility that valid connections are closed unnecessarily, it makes recovery from an application perspective more complicated.

• • Below is the procedure to configure the Connection Pool settings.
    • Login to the Webspehere Console Portal.
    • Expand “Resources ->JDBC ->” and click on “Datasources”. This will show the list of datasources already configured.
    • Pick up the Datasource (Say jdbc/mashupDS)
    • Under “Additional Properties” section, click on “Connection Pool Properties”
    • Examine above 7 properties for the selected datasource and update the value if required.

3. Thread Pool Settings

• It is recommended to set the connection pool size lower than the maximum thread pool connections of the web container.
• To configure this setting, click Servers > Server types > WebSphere application servers > server > Thread Pools, and modify the web container property. Lower settings, such as 10-30 connections, perform better than higher settings, such as 100.
• If you set a value for Aged timeout, connections with an expired age are discarded, regardless of the minimum pool size setting.

In the next blog we will discuss on the remaining tuning areas like “TeamworksConfiguration” and “Application Review and tuning”.

References
WebSphere Application Server Liberty Core 8.5.5. IBM Knowledge Center.