WebSphere Application Server performance tuning [ Connection Pool ]

Tune JVM Minimum and Maximum heap size

As the number of deployed applications grows, the use of heap size will increase and may exceed the maximum heap size. This can lead to potential problems: garbage collections will occur more frequently and will take longer time; our out of memory errors can occur if there is not enough memory to allocate in the heap. The heap size growth is also impacted by the expected number of concurrent requests and by the number or size of objects allocated throughout processing. Before increasing maximum heap size, it is important to measure whether the increase is needed due to legitimate application growth, or caused by potential memory leaks. If it is due to legitimate growth, the maximum heap size should be incremented not to exceed 50% of overall physical memory on the server. This measure may vary depending on what other processes are running on the server (e.g. other JVMs) and how much memory the OS allocates for system processes. They main goal is to avoid paging to disk as much as possible. Paging memory to disk translates into larger garbage collection times and consequently slower application response times.

The default initial heap size is 50MB and default maximum size is 256MB. In most cases the initial heap size should be set lower than the maximum heap size, however in cases where optimal performance is a priority specifying the same value for the initial and maximum heap size is recommended. The JVM heap size settings can be changed from the administrative console: Servers > Server Types > WebSphere application servers > server_name > Java and process management > Process definition > Java Virtual machine.

Tivoli Performance Viewer

Ideally your organization should use a robust monitoring solution to monitor for server and JVM health indicators and proactively alert when certain thresholds are reached. If your organization does not provide such tools, developers can use the Tivoli Performance Viewer included in WAS. The Performance Viewer allows monitoring for CPU usage, Java heap size usage, thread pool sizes, JDBC connection pool sizes, among many other indicators. The Performance Viewer is accessible from the administration console at: Monitoring and tuning > Performance Viewer > Current activity > server_name. You can then expand the different sections of interest and check on the indicators to be monitored. In the screenshot below we are monitoring for Heap Size, Process CPU Usage, Web Container’s thread pool size and WPSDB JDBC data source’s pool size.

Thread Pool

Set the thread pool values for an IBM® Sametime® Advanced server to improve performance. By using a thread pool, server components can reuse existing threads, which helps improve performance by reducing the overhead of creating new threads at run time.

1. From the Integrated Solutions Console, click Servers > Application Servers > stadvanced_server_name, and then under Additional Properties, click Thread Pools.
2. Click Default.
3. Change the values for Minimum Size and Maximum Size to 50.
4. Click OK, and click Save to save changes to the master configuration.
5. If Sametime Advanced is clustered, repeat the preceding steps for each node of the cluster

Runtime provisioning

Runtime provisioning is a feature introduced in WebSphere Application Server V7. It focuses on improving application server startup time by providing intelligent analysis of application set and server configuration to determine the needed subset of components to be loaded. This feature does not load an entire runtime library and thus decreases the memory footprint and shortens the start time.

There is no need for administrators and application developers to modify any processes to take advantage of the runtime provisioning. To turn this feature on, complete the following steps:

• Click Servers > Server Types > WebSphere application servers, as shown below:WebSphere application servers window

• 

• In the Application servers view, select your desired application server, as shown below: WebSphere application server view server selection

1. Select Start component as needed to enable runtime provisioning in this server, as shown below:Application servers configuration window
   

Configuring the JVM

As part of configuring an application server, you might define settings that enhance the way your operating system uses of the Java virtual machine (JVM).

The JVM is an interpretive computing engine that is responsible for running the byte codes in a compiled Java program. The JVM translates the Java byte codes into the native instructions of the host machine. The application server, being a Java process, requires a JVM to run and to support the Java applications running on it. JVM settings are part of an application server configuration.

To view and change the JVM configuration for an application server process, use the Java virtual machine page of the administrative console or use wsadmin scripts to change the configuration.

• In the administrative console, click Servers > Server Types > WebSphere application servers > server_name.

• Under Server Infrastructure, click Java and Process Management > Process definition.

• Select Java Virtual Machine.

• Specify values for the JVM settings in Generic JVM arguments text area as needed, and click OK.

• Click Save in the messages section of the administrative console panel to save the changes to the master configuration.

• Restart the application server.

Garbage collection (GC) is an integral part of the Java Virtual Machine (JVM) as it collects unused Java heap memory so that the application can continue allocating new objects. The effectiveness and performance of the GC play an important role in application performance and determinism. The IBM JVM provided with IBM WebSphere Application Server V8 (on supported platforms) provides four different GC policy algorithms:

• -Xgcpolicy:optthruput
• -Xgcpolicy:optavgpause
• -Xgcpolicy:gencon (default in WAS 8)
• -Xgcpolicy:balanced

Each of these algorithms provides different performance and deterministic qualities. In addition, the default policy in WebSphere Application Server V8 has changed from -Xgcpolicy:optthruput to the -Xgcpolicy:gencon policy.

Configuring connection pooling properties

Performance of an application that connects to a database can be greatly affected by the availability of connections to the database and how those connections affect the performance of the database itself. There are no simple rules that tell you how to configure the connection pool properties. Your configuration is highly dependent on application, network, and database characteristics. You need to coordinate the values that you specify in WebSphere closely with the database administrator.

Complete the following steps to access the connection pool properties:

1. Navigate to Resources > JDBC > Data sources and click the data source name.

1. Click Connection pool properties in the Additional Properties section.
   

The window shown in figure below opens

1. Specify the following information:
   • Connection TimeoutSpecify the interval, in seconds, after which a connection request times out and a ConnectionWaitTimeoutException is thrown. This action can occur when the pool is at its maximum (Maximum Connections) and all of the connections are in use by other applications for the duration of the wait.For example, if Connection Timeout is set to 300 and the maximum number of connections is reached, the Pool Manager waits for 300 seconds for an available physical connection. If a physical connection is not available within this time, the Pool Manager throws a ConnectionWaitTimeoutException.Tip: If Connection Timeout is set to 0, the pool manager waits as long as necessary until a connection is allocated.
   • Maximum ConnectionsSpecify the maximum number of physical connections that can be created in this pool.These connections are the physical connections to the back-end database. After this number is reached, no new physical connections are created and the requester waits until a physical connection that is currently in use is returned to the pool, or a ConnectionWaitTimeoutException is thrown.For example, if Maximum Connections is set to 5, and there are five physical connections in use, the Pool Manager waits for the amount of time specified in Connection Timeout for a physical connection to become free. If, after that time, there are still no free connections, the Pool Manager throws a ConnectionWaitTimeoutException to the application.
   • Minimum ConnectionsSpecify the minimum number of physical connections to be maintained. Until this number is reached, the pool maintenance thread does not discard any physical connections. However, no attempt is made to bring the number of connections up to this number.For example, if Minimum Connections is set to 3, and one physical connection is created, that connection is not discarded by the Unused Timeout thread. By the same token, the thread does not automatically create two additional physical connections to reach the Minimum Connections setting.
   • Reap TimeSpecify the interval, in seconds, between runs of the pool maintenance thread.For example, if Reap Time is set to 60, the pool maintenance thread runs every 60 seconds. The Reap Time interval affects the accuracy of the Unused Timeout and Aged Timeout settings. The smaller the interval you set, the greater the accuracy. When the pool maintenance thread runs, it discards any connections that have been unused for longer than the time value specified in Unused Timeout, until it reaches the number of connections specified in Minimum Connections. The pool maintenance thread also discards any connections that remain active longer than the time value specified in Aged Timeout.Tip: If the pool maintenance thread is enabled, set the Reap Time value less than the values of Unused Timeout and Aged Timeout.The Reap Time interval also affects performance. Smaller intervals mean that the pool maintenance thread runs more often and degrades performance.
   • Unused TimeoutSpecify the interval in seconds after which an unused or idle connection is discarded.Tips:
     • Set the Unused Timeout value higher than the Reap Timeout value for optimal performance. Unused physical connections are only discarded if the current number of connections not in use exceeds the Minimum Connections setting.
     • Make sure that the database server’s timeout for connections exceeds the Unused timeout property specified here. Long lived connections are normal and desirable for performance.For example, if the unused timeout value is set to 120, and the pool maintenance thread is enabled (Reap Time is not 0), any physical connection that remains unused for two minutes is discarded. Note that accuracy of this timeout, as well as performance, is affected by the Reap Time value. See the Reap Time bullet for more information.
   • Aged TimeoutSpecify the interval in seconds before a physical connection is discarded, regardless of recent usage activity.Setting Aged Timeout to 0 allows active physical connections to remain in the pool indefinitely. For example, if the Aged Timeout value is set to 1200, and the Reap Time value is not 0, any physical connection that remains in existence for 1200 seconds (20 minutes) is discarded from the pool. Note that accuracy of this timeout, as well as performance, is affected by the Reap Time value. See Reap Time for more information.Tip: Set the Aged Timeout value higher than the Reap Timeout value for optimal performance.
   • Purge PolicySpecify how to purge connections when a stale connection or fatal connection error is detected.Valid values are EntirePool and FailingConnectionOnly. If you choose EntirePool, all physical connections in the pool are destroyed when a stale connection is detected. If you choose FailingConnectionOnly, the pool attempts to destroy only the stale connection. The other connections remain in the pool. Final destruction of connections that are in use at the time of the error might be delayed. However, those connections are never returned to the pool.Tip: Many applications do not handle a StaleConnectionException in the code. Test and ensure that your applications can handle them.

WebSphere Application Server data source properties

You can set the properties that apply to the WebSphere Application Server connection, rather than to the database connection. To access the connection pool properties, navigate to Resources > JDBC > Data sources and click the data source name.

Click WebSphere Application Server data source properties in the Additional Properties section.

Clicking the link opens the window shown in figure below.

Specify the following information:

• Statement cache sizeSpecify the number of prepared statements that are cached per connection. A prepared statement is a precompiled SQL statement that is stored in a prepared statement object. This object is used to execute the given SQL statement multiple times. The WebSphere Application Server data source optimizes the processing of prepared statements.In general, the more statements your application has, the larger the cache should be. For example, if the application has five SQL statements, set the statement cache size to 5, so that each connection has five statements.Tip: This setting is vital to performance of the database and will most likely require tuning to suit the specific application. In general, the default is not high enough for best performance.
• Enable multithreaded access detectionIf you enable this feature, the application server detects the existence of access by multiple threads.
• Enable database reauthenticationConnection pool searches do not include the user name and password. If you enable this feature, a connection can still be retrieved from the pool, but you must extend the DataStoreHelper class to provide implementation of the doConnectionSetupPerTransaction() method where the reauthentication takes place.Connection reauthentication can help improve performance by reducing the impact of opening and closing connections, particularly for applications that always request connections with different user names and passwords.
• Enable JMS one-phase optimization supportActivating this support enables the Java Message Service (JMS) to get optimized connections from the data source. Activating this support also prevents JDBC applications from obtaining connections from the data source.
• Log missing transaction contextSpecifies whether the container issues an entry to the activity log when an application obtains a connection without a transaction context.
• Non-transactional data sourceSetting the flag to true will cause the Application Server to never enlist the connections from the data source in global or local transactions. Applications must explicitly call setAutoCommit(false) on the connection if they want to start a local transaction on the connection, and they must commit or roll back the transaction that they started. This property should rarely be set to true.
• Error detection modelThe error detection model has been expanded and the data source has a configuration option that you can use to select the exception mapping model or the exception checking model for error detection.
• Connection validation propertiesThere are two properties, and you can choose both. If you select the Validate new connections check box, the application server tries to connect to the database. If you select this property, you can specify how often, in seconds (interval).If you select the Validate existing pooled connections check box, the application server retries to make a connection. If you select this property, you can specify the retry interval for the server reroute. The pretest SQL string is sent to the database to test the connection.Tip: Connection validation by SQL query is deprecated in WebSphere Application Server V8.0. You can use validation by the JDBC Driver instead. If you use the property of validation by JDBC driver, you need JDBC 4.0 or later. If you do not have JDBC 4.0, you have to update the JDBC driver first.