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:
In the Application servers view, select your desired application server, as shown below:
Select Start component as needed to enable runtime provisioning in this server, as shown below:
Save the changes.
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:gencon (default in WAS 8)
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
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:
Navigate to Resources > JDBC > Data sources and click the data source name.
Click Connection pool properties in the Additional Properties section.
The window shown in figure below opens:
Specify the following information:
Specify 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
Tip: If Connection Timeout is set to 0, the pool manager waits as long as necessary until a connection is allocated.
Specify 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
Specify 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.
Specify 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.
Specify the interval in seconds after which an unused or idle connection is discarded.
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.
Specify 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.
Specify 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 size
Specify 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 detection
If you enable this feature, the application server detects the existence of access by multiple threads.
Enable database reauthentication
Connection 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 support
Activating 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 context
Specifies whether the container issues an entry to the activity log when an application obtains a connection without a transaction context.
Non-transactional data source
Setting 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 model
The 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 properties
There 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.