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 9, Configuring High Availability Session Persistence and Failover, in Sun GlassFish Enterprise Server v2.1.1 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 Enterprise 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.