Tuning Liberty

Tuning the JVM is a most important tuning step whether you configure a development or production environment. When you tune the JVM for Liberty, use the jvm.options file in the ${server.config.dir} directory. You can specify each of the JVM arguments that you want to use, one option per line. For more information, see Customizing the Liberty environment. An example of the jvm.options file is as follows:

-Xms50m
-Xmx256m

The transport channel services manage client connections, I/O processing for HTTP, thread pools, and connection pools. For applications on Liberty , the following attributes are available for different elements that can be used to improve runtime performance, scalability, or both.

httpOptions element

maxKeepAliveRequests

This attribute specifies the maximum number of persistent requests that are allowed on a single HTTP connection if persistent connections are enabled. A value of -1 means unlimited. This option supports low latency or high throughput applications, and SSL connections for use in situations where building up a new connection can be costly. Here is an example of how you code this option in the server.xml file:

<httpOptions maxKeepAliveRequests="-1" />

connectionManager element

maxPoolSize

This attribute specifies the maximum number of physical connections for the connection pool. The default value is 50. The optimal setting here depends on the application characteristics. For an application in which every thread obtains a connection to the database, you might start with a 1:1 mapping to the coreThreads attribute. Here is an example of how you code this option in the server.xml file:

<connectionManager ... maxPoolSize="40" /> 

purgePolicy

This attribute specifies which connections to destroy when a stale connection is detected in a pool. The default value is the entire pool. It might be better to purge only the failing connection. Here is an example of how you code this option in the server.xml file:

<connectionManager ... purgePolicy="FailingConnectionOnly" />

numConnectionsPerThreadLocal

This option specifies the number of database connections to cache for each executor thread. This setting can provide a major improvement on large multi-core (8+) machines by reserving the specified number of database connections for each thread.

Using thread local storage for connections can increase performance for applications on multi-threaded systems. When you set numConnectionsPerThreadLocal to 1 or more, these connections per thread are stored in thread local storage. When you use numConnectionsPerThreadLocal, consider two other values:

• The number of application threads
• The connection pool maximum connections

For best performance, if you have n applications threads, you must set the maximum pool connections to at least n times the value of the numConnectionsPerThreadLocal attribute and you must use the same credentials for all connection requests. For example, if you use 20 application threads, set the maximum pool connections to 20 or more; If you set the value of numConnectionPerThreadLocal attribute as 2 and there are 20 application threads, set the maximum pool connection to 40 or more. Here is an example of how you code this option in the server.xml file:

<connectionManager ... numConnectionsPerThreadLocal="1" /> 

dataSource element

statementCacheSize

This attribute specifies the maximum number of cached prepared statements per connection. To set this option, complete the following prerequisite:

• Review the application code (or an SQL trace that you gather from the database or database driver) for all unique prepared statements.
• Ensure that the cache size is larger than the number of statements.

Here is an example of how you code this option in the server.xml file:

<dataSource ... statementCacheSize="60" >

isolationLevel

The data source isolation level attribute specifies the degree of data integrity and concurrency, which in turns controls the level of database locking. Four different options are available as following in order of best performing (least integrity) to worst performing (best integrity).

TRANSACTION_READ_UNCOMMITTED

Dirty reads, non-repeatable reads, and phantom reads can occur.

TRANSACTION_READ_COMMITTED

Dirty reads are prevented; non-repeatable reads and phantom reads can occur.

TRANSACTION_REPEATABLE_READ

Dirty reads and non-repeatable reads are prevented; phantom reads can occur.

TRANSACTION_SERIALIZABLE

Dirty reads, non-repeatable reads, and phantom reads are prevented.

Here is an example of how you code this option in the server.xml file:

<dataSource ... isolationLevel="TRANSACTION_READ_COMMITTED">  

<applicationMonitor dropinsEnabled="false" updateTrigger="disabled"/>
<config updateTrigger="disabled"/>

The updateTrigger attribute can also be set to the value of mbean for both the applicationMonitor element and the config element. This setting allows applications and configurations to be updated by an MBean method. However, some amount of CPU time is used. To reduce the amount of CPU time used, you can set the pollingRate attribute of the applicationMonitor element and the monitorInterval attribute of the config element to large values. The following example shows how to reduce the amount of CPU time that is used when you set the updateTrigger attribute to the value of mbean:

<applicationMonitor updateTrigger="mbean" pollingRate="60s"/>
<config updateTrigger="mbean" monitorInterval="60s"/>