Tuning the Application Server for High-Availability

This section discusses how you can configure the high availability features of Application Server. This section discusses the following topics:

• Tuning Session Persistence Frequency

• Session Persistence Scope

• Session Size

• Checkpointing Stateful Session Beans

• Configuring the JDBC Connection Pool

• Descriptor configuration in the web application

To ensure highly available web applications with persistent session data, the high availability database (HADB) provides a backend store to save HTTP session data. However, there is a overhead involved in saving and reading the data back from HADB. Understanding the different schemes of session persistence and their impact on performance and availability will help you make decisions in configuring Application Server for high availability.

In general, maintain twice as many HADB nodes as there are application server instances. Every application server instance requires two HADB nodes.

Tuning Session Persistence Frequency

The Application Server provides HTTP session persistence and failover by writing session data to HADB. You can control the frequency at which the server writes to HADB by specifying the persistence frequency.

Specify the persistence frequency in the Admin Console under Configurations > config-name > Availability Service (Web Container Availability).

Persistence frequency can be set to:

• web-method

• time-based

All else being equal, time-based persistence frequency provides better performance but less availability than web-method persistence frequency. This is because the session state is written to the persistent store (HADB) at the time interval specified by the reap interval (default is 60 seconds). If the server instance fails within that interval, the session state will lose any updates since the last time the session information was written to HADB.

Web-method

With web-method persistence frequency, the server writes the HTTP session state to HADB before it responds to each client request. This can have an impact on response time that depends on the size of the data being persisted. Use this mode of persistence frequency for applications where availability is critical and some performance degradation is acceptable.

For more information on web-method persistence frequency, see Configuring Availability for the Web Container in Sun Java System Application Server Enterprise Edition 8.1 2005Q2 High Availability Administration Guide.

Time-based

With time-based persistence frequency, the server stores session information to the persistence store at a constant interval, called the reap interval. You specify the reap interval under Configurations > config-name > Web Container (Manager Properties), where config-name is the name of the configuration. By default, the reap interval is 60 seconds. Every time the reap interval elapses, a special thread “wakes up,” iterates over all the sessions in memory, and saves the session data.

In general, time-based persistence frequency will yield better performance than web-method, since the server’s responses to clients are not held back by saving session information to the HADB. Use this mode of persistence frequency when performance is more important than availability.

Session Persistence Scope

You can specify the scope of the persistence in addition to persistence frequency on the same page in the Admin Console where you specify persistence frequency, Configurations > config-name > Availability Service (Web Container Availability).

For detailed description of different persistence scopes, see Chapter 8, Configuring High Availability Session Persistence and Failover, in Sun Java System Application Server Enterprise Edition 8.1 2005Q2 High Availability Administration Guide.

Persistence scope can be one of:

• session

• modifed-session

• modified-attribute

session

With the session persistence scope, the server writes the entire session data to HADB—regardless of whether it has been modified. This mode ensures that the session data in the backend store is always current, but it degrades performance, since all the session data is persisted for every request.

modified-session

With the modified-session persistence scope, the server examines the state of the HTTP session. If and only if the data has been modified, the server saves the session data to HADB. This mode yields better performance than session mode, because calls to HADB to persist data occur only when the session is modified.

modified-attribute

With the modified-attribute persistence scope, there are no cross-references for the attributes, and the application uses setAttribute() and getAttribute() to manipulate HTTP session data. Applications written this way can take advantage of this session scope behavior to obtain better performance.

Session Size

It is critical to be aware of the impact of HTTP session size on performance. Performance has an inverse relationship with the size of the session data that needs to be persisted. Session data is stored in HADB in a serialized manner. There is an overhead in serializing the data and inserting it as a BLOB and also deserializing it for retrieval.

Tests have shown that for a session size up to 24KB, performance remains unchanged. When the session size exceeds 100KB, and the same back-end store is used for the same number of connections, throughput drops by 90%.

It is important to pay attention while determining the HTTP session size. If you are creating large HTTP session objects, calculate the HADB nodes as discussed in Tuning HADB.

Checkpointing Stateful Session Beans

Checkpointing saves a stateful session bean (SFSB) state to the HADB so that if the server instance fails, the SFSB is failed over to another instance in the cluster and the bean state recovered. The size of the data being checkpointed and the frequency at which checkpointing happens determine the additional overhead in response time for a given client interaction.

You can enable SFSB checkpointing at numerous different levels:

• For the entire server instance or EJB container

• For the entire application

• For a specific EJB module

• Per method in an individual EJB module

  For best performance, specify checkpointing only for methods that alter the bean state significantly, by adding the <checkpointed-methods> tag in the sun-ejb-jar.xml file.

  For more information, see Using Session Beans in Sun Java System Application Server Enterprise Edition 8.1 2005Q2 Developer’s Guide.

Configuring the JDBC Connection Pool

The Application Server uses JDBC to store and retrieve HADB data. For best performance, configure the JDBC connection pool for the fastest possible HADB read/write operations.

Configure the JDBC connection pool in the Admin Console under Resources > JDBC > Connection Pools > pool-name. The connection pool configuration settings are:

• Initial and Minimum Pool Size: Minimum and initial number of connections maintained in the pool (default is 8)

• Maximum Pool Size: Maximum number of connections that can be created to satisfy client requests (default is 32)

• Pool Resize Quantity: Number of connections to be removed when idle timeout timer expires

• Idle Timeout: Maximum time (seconds) that a connection can remain idle in the pool. (default is 300)

• Max Wait Time: Amount of time (milliseconds) caller waits before connection timeout is sent

For optimal performance, use a pool with eight to 16 connections per node. For example, if you have four nodes configured, then the steady-pool size must be set to 32 and the maximum pool size must be 64. Adjust the Idle Timeout and Pool Resize Quantity values based on monitoring statistics.

For the best performance, use the following settings:

• Connection Validation: Required

• Validation Method: metadata

• Transaction Isolation Level: repeatable-read

In addition to the standard attributes, add the two following properties:

• cacheDatabaseMetaData: false

• eliminateRedundantEndTransaction: true

To add a property, click the Add Property button, then specify the property name and value, and click Save.

For more information on configuring the JDBC connection pool, see Tuning JDBC Connection Pools.