WebSphere Tuning Approach
Session Replication – WebSphere Tuning
Copying the session data of users to a remote store is known as session replication. In the event of a failure, this data could be retrieved. If there is an issue, another process can handle all other requests by retrieving the appropriate session content. This is very essential in case of highly available systems as you need to provide all users with an uninterrupted browser experience.
Tuning Considerations
When session replication is enabled, here are four factors to be considered in tuning the environment:
- Write frequency
- Write contents
- Session timeout
- Background session invalidation interval
Write frequency
Write frequency is an important factor in session replication reliability and performance. Write frequency can dictate how often the sessions are replicated to the domain. As the interval between the replicates (i.e. write frequency) is minimized, the performance is decreased. This is because the CPU cycles are being used more frequently to replicate the data instead of handling subsequent requests. The three options of write frequency setting are Time based write, End of servlet service and Manual.
Time based write can write latest session information to the back-end on a time interval. For instance, if a user makes four requests between a given write interval then it is considered as just one update. This setting could be utilized for maximum performance and the default value is 10 seconds.
End of Servlet service writes the updated information after the execution of servlet. You can use this setting for failover support and maximum reliability.
Manual gives developers the most flexibility as to when the session is backed up, but the owner of the application should consider this mode with caution.
Write contents
The Write contents factor denotes whether “Only updated attributes” or “All session attributes” should be persisted. It is advised to use “Only updated attributes” option so that you can minimize overhead of persisting data that has not changed.
Note: You must use the “write all” setting if you are unable to call setAttribute on an updated session attribute.
Session timeout
The session timeout specifies the validity of a session. The default value of the timeout is 30 minutes. So after a session is accessed, it is valid for 30 minutes. You can increase this value if sessions are going to be idle for more than 30 minutes. By decreasing this value, you can invalidate the sessions faster. Unused sessions could be invalidated quickly with small values of session timeout.
Background session invalidation interval
This is the interval at which a background process looks for timed out sessions that should be invalidated. This value is actually based on session timeout value and an internal algorithm. The default value is 150 seconds.
Controlling Memory Buffers – WebSphere Tuning
Every messaging engine manages few memory buffers. By setting the buffer sizes, you can enhance the communication of a messaging engine with its data store.
You can set the following properties:
sib.msgstore.discardableDataBufferSize
Here the default value is 320000 (i.e. around 320 kilobytes). The discard-able data buffer contains the data related to active transactions and any other non-persistent data that the messaging engine has neither consumed nor discarded.
The messaging engine holds this data completely within this memory buffer and never writes it to the data store. When the messaging engine includes data to the discard-able data buffer, it may discard the existing data in the buffer to create certain space.
The messaging engine can only discard data that is not involved in active transactions. This behavior helps the engine to get rid of best effort non-persistent messages.
By increasing the discard-able data buffer size, more best effort non-persistent data has to be handled before the engine begins discarding.
sib.msgstore.cachedDataBufferSize
The cached data buffer can optimize the performance of the messaging engine. The default value is 320 kilobytes. The messaging engine adds data to the cached data buffer as it is written and read from the data store. As mentioned above, the engine may discard the existing data in the buffer to create certain space.
sib.msgstore.transactionSendLimit
This denotes the maximum number of operations that an engine can include in each transaction. For instance, each JMS send or receive is an operation that is being counted towards the transaction send limit. Its default value is 100.