Tune the Liberty profile

We can tune parameters and attributes of the Liberty profile.

The Liberty profile supports different attributes in server.xml to influence application performance. We can use these parameters and attributes to achieve better performance. To tune the Liberty profile for secure applications, see Tuning the Liberty profile for secure applications.

• Tune the JVM.

  Tune the JVM is a most important tuning step whether we configure a development or production environment. When we tune the JVM for the Liberty profile, use the jvm.options file in the ${server.config.dir} directory. We can specify each of the JVM arguments to use, one option per line.

  See Customize the Liberty profile environment. An example of the jvm.options file is as follows:

  -Xms50m
  -Xmx256m

  For a development environment, we 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 the 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 Configuration elements in server.xml.

  maxKeepAliveRequests of httpOptions

  This option specifies the maximum number of persistent requests 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 server.xml:

  <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 that are associated with the executor can 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.

  Start the 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 server.xml:

  <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, we might start with a 1:1 mapping to the coreThreads attribute. Here is an example of how you code this option in server.xml:

  <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 server.xml:

  <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.

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

  • The number of application threads

  • The connection pool maximum connections

  For best performance, if we have n applications threads, set the maximum pool connections to at least n times the value of the numConnectionsPerThreadLocal attribute and use the same credentials for all connection requests. For example, if we 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 server.xml:

  <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 server.xml:

  <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 server.xml:

  <dataSource ... isolationLevel="TRANSACTION_READ_COMMITTED">

• Decrease response time of servlets

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

  <webContainerskipMetaInfResourcesProcessing="true"/>

• Reducing idle server CPU time

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

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

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

  For more information about the configuration element descriptions, see Configuration elements in server.xml.

Subtopics

• Tune the Liberty profile for secure applications
  We can tune the Liberty profile to maximize the performance for secure applications.

• 

  Tune federated LDAP repositories
  We can improve the performance of the federated LDAP repositories by monitoring and adjusting the cache and the context pool elements in server.xml.

Reference:

Directory locations

Configuration elements in server.xml