Http Session Tuning - Cache size

The session data is stored in cache and The Maximum in session memory count number has different meanings, depending on session support configuration:

• With in-memory sessions, session access is optimized for up to this number of sessions.


• With distributed sessions (meaning, when sessions are stored in a database or in another WebSphere Application Server instance); it also specifies the cache size and the number of last access time updates saved in manual update mode.

For distributed sessions, when the session cache has reached its maximum size and a new session is requested, the Session Management facility removes the least recently used session from the cache to make room for the new one. General memory requirements for the hardware system, and the usage characteristics of the e-business site, determines the optimum value. Note that increasing the base in-memory session pool size can necessitate increasing the heap sizes of the Java processes for the corresponding WebSphere Application Servers.

By default, the number of sessions maintained in memory is specified by base in-memory session pool size. If you do not wish to place a limit on the number of sessions maintained in memory and allow overflow, set overflow to true. Allowing an unlimited amount of sessions can potentially exhaust system memory and even allow for system sabotage. Someone could write a malicious program that continually hits your site and creates sessions, but ignores any cookies or encoded URLs and never utilizes the same session from one HTTP request to the next. When overflow is disallowed, the Session Management facility still returns a session with the HttpServletRequest getSession(true) method when the memory limit is reached, and this is an invalid session that is not saved

Http Session tuning - Schedule Session Cleanup

Instead of relying on the periodic invalidation timer that runs on an interval based on the session timeout parameter, you can set specific times for the session management facility to scan for invalidated sessions in a distributed environment.




When used with distributed sessions, this feature has the following benefits:

• You can schedule the scan for invalidated sessions for times of low application server activity, avoiding contention between invalidation scans of database or another WebSphere Application Server instance and read and write operations to service HTTP session requests.


• Significantly fewer external write operations can occur when running with the End of Service Method Write mode because the last access time of the session does not need to be written out on each HTTP request. (Manual Update options and Time Based Write options already minimize the writing of the last access time.)

Enables the scheduled invalidation process for cleaning up the invalidated HTTP sessions from the external location. Enable this option to reduce the number of updates to a database or another application server instance required to keep the HTTP sessions alive. When this option is not enabled, the invalidator process runs every few minutes to remove invalidated HTTP sessions. When this option is enabled, specify the two hours of a day for the process to clean up the invalidated sessions in the external location. Specify the times when there is the least activity in the application servers. An external location can be either a database or another application server instance.

• First Time of Day (0 - 23): Indicates the first hour during which the invalidated sessions are cleared from the external location. Specify this value as a positive integer between 0 and 23. This value is valid only when schedule invalidation is enabled


• Second Time of Day (0 - 23): Indicates the second hour during which the invalidated sessions are cleared from the external location. Specify this value as a positive integer between 0 and 23. This value is valid only when schedule invalidation is enabled.

Http Session Tuning - Write Frequency

In the Session Management facility, you can configure the frequency for writing session data to the database or to a WebSphere instance, depending on whether you use database distributed sessions or memory-to-memory replication. This flexibility enables you to weigh session performance gains against varying degrees of failover support.





The following options are available in the Session Management facility for tuning write frequency:

• End of service servlet- Write session data at the end of the servlet service method call.


• Manual update- Write session data only when the servlet calls the IBMSession.sync method.


• Time based (the default) - Write session data at periodic intervals, in seconds (called the write interval).

When a session is first created, session information is always written at the end of the service call.Using the time based write or manual update options can result in loss of data in failover scenarios since the backup copy of the session in the persistent store (for example, a database or another JVM) may not be in sync with the session in the session cache.

Session Management tuning

WebSphere Application Server session support has features for tuning session performance and operating characteristics, particularly when sessions are configured in a distributed environment.

WAS admin console provides some predefined session tuning to choose from, you can select either one of them



If you want more precise control over the session tuning, select custom Setting level

Application performance consideration - Asynchronous architecture

Consider asynchronous architecture when possible because that supports optimial scheduling of workloads and minimal server resrouce.

An example of this difference is an application that enables you to submit a purchase order, enables you to continue while the system validates the order, queries remote systems, and in the future informs you of the purchase order status. This example can be implemented synchronously with the client waiting for the response. The synchronous implementation requires application server resources and you wait until the entire operations complete. If the process enables you to continue, while the result is computed asynchronously, the application server can schedule the processing to occur when it is optimal in relation to other requests. The notification to you can be triggered through e-mail or some other interface within the application.

WebSphere Application Server supports asynchronous programming through J2EE Java Message Service (JMS) and message-driven beans (MDB) as well as asynchronous beans

Application performance consideration - cacihng

Most J2EE application workloads have more read operations than write operations. Read operations require passing a request through several topology levels that consist of a front-end Web server, the Web container of an application server, the EJB container of an application server, and a database. WebSphere Application Server provides the ability to cache results at all levels of the network topology and J2EE programming model that include Web services.Application designers must consider caching when the application architecture is designed because caching integrates at most levels of the programming model.

Network designers must consider caching when network planning is performed because caching also integrates at most levels of the network topology. For applications that are available on the public Internet, network designers might want to consider Edge Side Include (ESI) caching when WebSphere Application Server caching extends into the public Internet. Network caching services are available in the proxy server for WebSphere Application Server, WebSphere Edge Component Caching Proxy, and the WebSphere plug-in.

Application performance consideration - web layer

You should always use the Model-View-Controller architecture for developing web applications. The MVC pattern requires distinct separation of the view, controller and athe model. Using the MVC pattern enables optimization of the performacne and scalability of each layer separately If possible try creating statless application i.e. application which does not store any state on the server. If not try keeping the size of state data as well as time for which state data should be stored to minimum.

Also, if state storage is needed, consider the possibility of reconstructing the state if failure occurs, instead of guranteeing state through replication. What this means is if you want to develop an application that stores data in HttpSession, instead of enabling distributed session to handle failover, try developing your application so that it checks if the attributes are present in session, if not recreate those attributes.

Application performance consideration - persistence

The persistence mechanism usually involves the JDBC API. Because JDBC requires manaul coding, the SQL that runs against a database instance, it is critical to optimize the SQL statement that are used within the application. Also, conifgure the database server to support the optimal performance of these SQL statements.

If your using JDBC API, you must consider including prepared statements and batching. Also always use the container managed transactions.

You should tune data source for optimial performance.

Important Note: In general, the type 2 JDBC driver is recommended. However, the type 4 JDBC drivers perform faster in the area of multi-row fetch.

Some applications generate a high rate of writes to the WebSphere Application Server transaction log. Locating the transaction log on a fast disk or disk array can improve response time