Tuning Liberty

You can tune parameters and attributes of Liberty.

• Tune the JVM.
  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

  For a development environment, you might be interested in faster server startup. So, consider setting the minimum heap size to a small value, and the maximum heap size to whatever value is needed for your application. For a production environment, setting the minimum heap size and maximum heap size to the same value can provide the best performance by avoiding heap expansion and contraction.

• Tune transport channel services.
  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.

  maxKeepAliveRequests of httpOptions

  This option 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" />

  maxPoolSize of connectionManager

  This option 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 of connectionManager

  This option 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 of connectionManager

  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" /> 

  statementCacheSize of dataSource

  This option 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 of dataSource

  The data source isolation level 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">  

• Tune the default executor.

  The Liberty default executor is self-tuning and adapts to the current workload by dynamically adding or removing threads. For most workloads, the executor does not require any tuning, and you are advised not to change any settings of the executor unless you encounter specific problems with thread creation.

  If necessary, you can configure the coreThreads and maxThreads parameters of the executor element in the server.xml file to set lower and upper bounds for the Liberty auto-tuning code. The coreThreads setting is not usually needed because the executor contains aggressive anti-deadlocking code that adds threads to break the executor out of deadlock scenarios. Rarely, the anti-deadlocking code adds more threads than are required. In this situation, you can use the maxThreads parameter of the executor element to cap the number of threads the executor is allowed to create.

  Note: As of 18.0.0.1, the thread growth algorithm is enhanced to grow thread capacity more aggressively so as to react more rapidly to peak loads. If after upgrading to fix pack 18.0.0.1 (or beyond) you experience errors or exceptions indicating that the JVM is unable to create a thread, you might need to retune these settings or any other operating system environmental settings that limit your threads.
• Decrease response time of servlets.

  To decrease response time of servlets, add the following attribute to the server.xml file:

  <webContainer skipMetaInfResourcesProcessing="true"/>

• Reduce idle server CPU time.

  To reduce idle server CPU time, add the following attributes to the server.xml file:

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

  When the attributes are added, your server no longer monitors for configuration or application updates.

  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"/>

• Tuning startup time.

  CDI 1.2

  By default, the CDI 1.2 feature scans all application archives. The CDI 1.2 feature can increase startup time substantially and have the most effect on larger applications. Implicit archive scanning for annotations can be disabled by setting enableImplicitBeanArchives value to false. This setting skips the scanning of archives unless they contain a beans.xml file.

  <cdi12 enableImplicitBeanArchives="false"/>

  Note: The cdi-1.2 feature might be included even if it is not in the <features> section of your server.xml file because other features, such as webProfile-7.0 and javaee-7.0, include the cdi-1.2 feature. Look in the messages.log file for The server installed the following features: to see whether cdi-1.2 was installed.