To calculate load on the HADB, consider the following factors:
For instructions on configuring session persistence, see Chapter 7, Configuring High Availability Session Persistence and Failover, in Sun GlassFish Enterprise Server 2.1 High Availability Administration Guide.
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. |
The session size per request depends on the amount of session information stored in the session.
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.
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.