Tuning the Liberty profile

You can tune parameters and attributes of the Liberty profile.

• 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 the Liberty profile, 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. See Customizing the Liberty profile environment for more information. An example of 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 the Liberty profile, the following attributes are available for different elements that can be used to improve runtime performance, scalability, or both. For each of these attributes, see Liberty profile: Configuration elements in the server.xml file.

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

  coreThreads of executor

  This option specifies the core number of threads to associate with the executor of the thread pool. The number of threads associated with the executor will quickly grow to this number. If this value is less than 0, a default value is used. This default value is calculated based on the number of hardware threads on the system.

  Tip: Start your tuning with coreThreads="5" for each hardware thread or logical processor. For example, for a two-core SMT-4 machine, which represents eight logical processors, use coreThreads="40" as a starting point.

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

  <executor name="LargeThreadPool" id="default" coreThreads="40" maxThreads="80" 
            keepAlive="60s" stealPolicy="STRICT" rejectedWorkPolicy="CALLER_RUNS" /> 

  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 setting numConnectionsPerThreadLocal to 1 or more, these connections per thread are stored in thread local storage. When using numConnectionsPerThreadLocal, consider two other values:

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

  For best performance, if you have n applications threads, set maximum pool connections to at least n times the value of numConnectionsPerThreadLocal attribute. 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 gathered from the database or database driver) for all unique prepared statements.
  • Ensure 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">  

• Decrease response time of servlets

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

  <webContainerskipMetaInfResourcesProcessing="true"/>

• Reducing idle server CPU time

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

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