You can tune parameters and attributes of the Liberty profile.
About this task
The Liberty profile supports different attributes in the
server.xml file
to influence application performance. You 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.
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. For more information, see
Customizing the Liberty profile 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 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 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.
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 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">
- 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 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.
For more
information about the configuration element descriptions, see
Liberty profile: Configuration elements in the server.xml file.