Sun Java System Application Server Enterprise Edition 8.1 2005Q2 Deployment Planning Guide

- Previous: Estimating Load on Application Server Instances
- Next: Planning the Network Configuration

## Estimating Load on the HADB

To calculate load on the HADB, consider the following factors:

- HTTP Session Persistence Frequency

- HTTP Session Size and Scope

- Stateful Session Bean Checkpointing

For instructions on configuring session persistence, 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.

### HTTP Session Persistence Frequency

The number of requests per minute received by the HADB depends on the persistence frequency. Persistence Frequency determines how often Application Server saves HTTP session data to the HADB.

The persistence frequency options are:

- web-method (default): the server stores session data with every HTTP response. This option guarantees that stored session information will be up to date, but leads to high traffic to HADB.

- time-based: the session is stored at the specified time interval. This option reduces the traffic to HADB, but does not guarantee that the session information will be up to date.

The following table summarizes the advantages and disadvantages of persistence frequency options.

Table 2–1 Comparison of Persistence Frequency Options

Persistence Frequency Option | Advantages | Disadvantages
--- | --- | ---
web-method | Guarantees that the most up-to-date session information is available. | Potentially increased response time and reduced throughput.
time-based | Better response time and potentially better throughput. | Less guarantee that the most updated session information is available after the failure of an application server instance.

### HTTP Session Size and Scope

The session size per request depends on the amount of session information stored in the session.

Tip –

To improve overall performance, reduce the amount of information in the session as much as possible.

It is possible to fine-tune the session size per request through the `persistence scope` settings. Choose from the following options for HTTP session persistence scope:

- session: The server serializes and saves the entire session object every time it saves session information to HADB.

- modified-session: The server saves the session only if the session has been modified. It detects modification by intercepting calls to the bean’s `setAttribute()` method. This option will not detect direct modifications to inner objects, so in such cases the SFSB must be coded to call `setAttribute()` explicitly.

- modified-attribute: The server saves only those attributes that have been modified (inserted, updated, or deleted) since the last time the session was stored. This has the same drawback as modified-session but can significantly reduce HADB write throughput requirements if properly applied.

To use this option, the application must:

- Call `setAttribute()` or `removeAttribute()` every time it modifies session state.

- Make sure there are no cross references between attributes.

- Distribute the session state across multiple attributes, or at least between a read-only attribute and a modifiable attribute.

  The following table summarizes the advantages and disadvantages of the persistence scope options.

Table 2–2 Comparison of Persistence Scope Options

Persistence Scope Option | Advantages | Disadvantages
--- | --- | ---
modified-session | Provides improved response time for requests that do not modify session state. | During the execution of a web method, typically `doGet()` or `doPost(`), the application must call a session method: `setAttribute()` if the attribute was changed `removeAttribute()` if the attribute was removed.
session | No constraint on applications. | Potentially poorer throughput and response time as compared to the `modified-session` and the `modified-attribute` options.
modified-attribute | Better throughput and response time for requests in which the percentage of session state modified is low. | As the percentage of session state modified for a given request nears 60%, throughput and response time degrade. In such cases, the performance is worse than the other options because of the overhead of splitting the attributes into separate records.

### Stateful Session Bean Checkpointing

For SFSB session persistence, the load on HADB depends on the following:

- Number of SFSBs enabled for checkpointing.

- Which SFSB methods are selected for checkpointing, and how often they are used.

- Size of the session object.

- Which methods are transactional.

Checkpointing generally occurs after any transaction involving the SFSB is completed (even if the transaction rolls back).

For better performance, specify a small set of methods for checkpointing. The size of the data that is being checkpointed and the frequency of checkpointing determine the additional overhead in response time for a given client interaction.

- Previous: Estimating Load on Application Server Instances
- Next: Planning the Network Configuration

- © 2010, Oracle Corporation and/or its affiliates