Skip to main contentCúram Performance & Tuning Guide

Tuning JDBC connection pool settings

Set the JDBC connection pools for the Cúram data sources.

Data source: jdbc/curamdb

A Cúram transaction can require two JDBC connections, one for the transaction itself and another one for the key server. Size thejdbc/curamdb data source connection pool to prevent deadlocks, with more connections available than threads that Cúram uses. Therefore, size the connection pool for the jdbc/curamdb data source by using the following formula:


WebSphere
max_connections = WebContainer_max_threads + SIBJMSRAThreadPool_max_threads + 1

WebLogic
max_connections = default_max_thread_constraint + MDBWorkManager_max_thread_constraint + 1

If a firewall exists between the application servers and the database, to prevent issues that are related to StaleConnectionException, we recommend setting min_connections = 0 and reapTime<= unused connection timeout <= firewall timeout.

As a starting value for Cúram, set the data source prepared statement cache size for jdbc/curamdb to 1000. Then, monitor the cache use and increase it if discards occur. In our experience, preventing discards can increase throughput by up to 20%.

Note: While we recommend an initial value of 1000 for the prepared statement cache to prevent discards, this value can be too high for Cúram-based systems that have many threads and that are memory constrained. In that case, it is recommended to review the SQLStats from the JMX Stats, from either load tests or production. Then, use a simple heuristic based on the distribution of SQL executions to find a smaller cache size that covers around 90% of SQL executions from the application and gives a better balance between system performance and Java™ heap utilization. However, monitor prepared statement cache discards, system performance, and heap utilization, and adjust the cache size further as needed.

Data source: jdbc/curamsibdb

As all Cúram transactions can potentially create a JMS message, size the connection pool for the jdbc/curamsibdb data source by using the following formula:


WebSphere
max_connections = WebContainer_max_threads + SIBJMSRAThreadPool_max_threads + 1

WebLogic
max_connections = default_max_thread_constraint + MDBWorkManager_max_thread_constraint + 1

To prevent the processing cost of pool growth and shrinkage, it is suggested to setmin_connections = max_connections.

If a firewall exists between the application servers and the database, to prevent issues that are related to StaleConnectionException, we recommend setting min_connections = 0 and reapTime<= unused connection timeout <= firewall timeout.

Data source: jdbc/curamtimerdb

The EJB timer service is used by all Cúram transactions, but only once per transaction, in our application infrastructure and at the very start of an Cúram transaction. Currently, no reference to or usage of this service exists after the very start of an Cúram transaction.

You can tune the size of the jdbc/curamtimerdb data source connection pool to be the same size as the number of threads, which would ensure that no contention can occur on the pool. However, given that the time that is spent using the EJB timer service is typically short compared to the duration of the transactions, a smaller size should work well without significant contention. So our advice is to start with the default size, monitor the system, and then increase the size if evidence exists of a significant contention under normal conditions.

We have not had to resize the jdbc/curamtimerdb data source connection pool in our load tests of Cúram in a default installation, where our application servers are tuned for high throughput and memory protection. In such an environment, the number of threads is a low multiplier of the number of cores that are available to the application server, as documented in the Thread pools section.

Previous
Tuning the application server: Thread Pools
Next
Tuning the application server: JMS Settings