A lot of JEE application developers and WebSphere system administrators struggle to establish a size for the HTTPSession. It is a recommended best practice to keep session data sizes small and leverage a POJO cache like the Dynacache Distributedmap to store long running data.
Section 12.10.1 of WebSphere Application Server V7 Administration and Configuration Guide gives the following guidance on session size: "In general, you can obtain the best performance with session objects that are less than 2 KB in size. When the session object exceeds 4-5 KB, you can expect a significant decrease in performance."
I believe this advice is correct in intent but should not be taken literally. The part of that quote that is misleading is the text "When the session object exceeds 4-5 KB, you can expect a significant decrease in performance." This is not necessarily true in all cases as the ideal HTTPSession size varies by application and depends on the performance characteristics and function of the application.
I believe this advice is correct in intent but should not be taken literally. The part of that quote that is misleading is the text "When the session object exceeds 4-5 KB, you can expect a significant decrease in performance." This is not necessarily true in all cases as the ideal HTTPSession size varies by application and depends on the performance characteristics and function of the application.
Even if session persistence is not an issue, minimizing the session object size will help protect your Web application from scale-up disasters as user numbers increase. Large session objects will require more and more JVM memory, leaving no room to run servlets.
If you are a system administrator and need to determine How big your WebSphere HTTP sessions are? ( and what's in them?) read this excellent L3 session troubleshooting blog post from WebSphere Java guru Chris Bailey.
If you are a architect and need to determine an overall strategy for HTTPSession size and persistence read Chapter 12 in the WebSphere 7 Administration and Configuration redbook as well as this session persistence article from Erik Burckart.
For profiling the HTTP session sizes using OQL in Memory Analyzer
SELECT data as "MemorySessionData", data.@usedHeapSize as "Heap Size", data.@retainedHeapSize as "Retained Heap Size",mSwappableData, toString(data.mManager.scAppParms._J2EEName) as "J2EE Name", toString(data.appName) as "App Name", toString(data.mSessionId) as "Session ID" FROM com.ibm.ws.webcontainer.httpsession.MemorySessionData data
These resources together with the WebSphere Infocenter articles on session persistence will help you establish the right session persistence strategy and  size for your application.
Please also see WebSphere Session Persistence Best Practice blob post.
Please also see WebSphere Session Persistence Best Practice blob post.
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.