2.2 Session persistence considerationsUnless you have only a single appserver or your application is completely stateless, maintaining state between HTTP client requests is also a factor in determining your topology. Use of session information, however, presents a fine line between convenience for the developer and performance and scalability of the system. It is impractical to eliminate session data altogether, but try to minimize the amount of session data passed. Persistence mechanisms decrease the capacity of the overall system, or incur additional costs to increase the capacity or even the number of servers. Therefore, when designing your WebSphere environment, take session needs into account as early as possible. If the application maintains state between HTTP requests and you use vertical or horizontal scaling, then consider using an appropriate strategy for session management. Each appserver runs in its own JVM process. To allow a failover from one appserver to another without losing state, we need to share the session data between multiple processes. There are two methods of achieving this in WebSphere Application Server Network Deployment:
This method employs Data Replication Service (DRS) to provide replication of session data between the process memory of different appserver JVMs. DRS is included with WebSphere Application Server and is automatically started when the JVM of a clustered member starts. It also does not require a separate database to store the persistent states, and eliminates a single point of failure found in the session database if the database itself has not been made highly available using clustering software.
With this method, session data is stored in a database shared by all appservers. It requires external clustering software to make it highly available. The default maximum pool size of 10 is a useful starting point when you size the connection pool for database persistence. You may want to increase it if your session object is quite large, or your site handles thousands of concurrent users.
For larger session sizes, the overhead of session replication increases. Database replication has a lower overall throughput than memory-to-memory due to database I/O limitations (the database becomes a bottleneck). However, although like database replication with large sessions performs slower, less CPU power is used than with memory-to-memory replication, and the unused processor power can be used by other tasks on the system. Also, storing session states in a persistent database or using memory-to-memory replication provides a degree of fault tolerance to the system. If an appserver crashes or stops, any session state that it may have been working on would normally still be available either in the back-end database or in the running appserver's memory, so that other appservers can take over and continue processing subsequent client requests associated with that session. Neither mechanism provides a 100% guarantee that a session state will be preserved in case of a server crash. However, such a situation represents only a very small window of vulnerability, and a very small percentage of all occurrences that typically happen throughout the life of a system in production. The overhead of replicating session information might be significant, depending on the number of appservers in your cluster and the size of the sessions. In these situations, database persistence might be the better choice in a memory-constrained environment. The question becomes, how to choose one option over the other. For configurations where cross-cell session failover is a requirement, then database persistence might be the better choice. In a cascading failure, the database may survive, although memory-to-memory replicators may not. Similarly, with memory-to-memory, there can only be a single replicator common to the cells, which leads to a single point of failure (SPOF). Keep in mind that most of the cost of replication is incurred in the serialization and deserialization of the session object, and this applies to both cases. Also in both cases, as a session object's size increases, performance decreases. Ultimately, your decision will depend upon your application availability requirements, the quality of service needed for your applications, and your comfort zone for the technology, whether database or memory-to-memory. |
