Session context size
This section contains recommended best practices on how to minimize the
allocation of data in the BTT session context. The BTT session context stores
the data that a given user needs across several requests. It is usually the
major consumer of memory resources in the server. The average size of this
data determines how many users can be allocated in a given JVM; thus highly
impacting the application's scalability. Moreover, if session persistence
is used, for example in order to enable transparent failover, the session
size becomes more critical because it greatly impacts performance, given that
all the session data will be serialized at the end of each request.
The recommendations for minimizing the session context size are as follows:
- Session size profiling: Calculate the average session size of the
application in order to ensure that the available hardware can allocate the
planned number of users.
A profiling done with tools such as LoadRunner
or Rational® Application
Developer (RAD) will help determine the exact size of a given session instance.
Whereas, WAS Performance Monitoring Infrastructure (PMI) can directly report
the average HttpSession size in a server.
- Session size capacity planning: The following calculations should
be performed for each WebSphere® cluster where BTT is planned to be installed:
- Determine the memory available to the application (JVM size) per server.
- Keep failover in mind. In the case where one server in the cluster is
down, the rest of the servers should still be able to allocate the extra resources.
This means that you must account for one server less than the total number
of servers available.
- Divide the total available memory by the planned number of users.
This will result in a rough estimation of the maximum session size.
If, after profiling, the average session size is close to this maximum, the
application should be modified in order to reduce its session size.
- Reducing session size: The following tips can be applied when designing
or reviewing the session context.
If session persistence is enabled, the following recommendations should
also be considered in order to reduce the performance impact of the persistence
process:
- Persistence performance impact is mostly caused by the serialization process.
It is therefore very beneficial to provide a custom serialization implementation
for the data being serialized. With the BTT framework, this means usually
only the DataField, KeyedCollection and IndexedCollection will need to be
extended, since all context data is stored in this kind of structures.
- Instead of serializing all session context data after every request, consider
developing an extension that marks which objects have been updated, then design
your persistence database so that each different session object is stored
in a separate field. This approach can have great performance benefits, but
is difficult to implement and may require active participation of the application
code, that is to notify whenever an object has been modified so it can be
appropriately marked for serialization.