This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
I'm having a brain fart here, maybe someone can help me out.
There is a way to measure the size of a user's http session. I cannot, for the life of me, remember what it is.
We are storing a lot of data inside the user session and I want to find out how large it is getting. This is actually very important because we are trying to find ways to improve performance at all levels of our application and if the session is getting too large then I am going to recommend we consider moving some data into the request if we don't need to persist it.
But first I want to see how large the session is because if it isn't really that big then there is no point in pursuing that route right away. Frankly, I suspect I can achieve most of our performance goals by tweaking our back-end code. I just don't want to ignore this potential issue.
This is not a very easy question to answer. Partially because the implementation of a session varies from platform to platform and you haven't identified what language this is.
Generally what you could do is iterate through your collection and spit out all the variables that will give you an idea.
But even then it's flaky. This is sort of like asking how much memory a given Object will use... you really dont' know and you shouldn't really care.
Joined: Jan 21, 2004
I had thought about doing just that, having everything dumped out to a file and seeing how big it is. But, like you said, that would just be a rough idea.
I am interested in the actual session the browser is storing. I could have sworn I'd seen some kind of metric for finding its size somewhere and if my engineer was around I could just ask him since I believe he was the one that had it.
Generally I wouldn't care so much about this, but we're down to shaving bytes. I expect to get a lion's share of the performance back by optimizing the Java back-end and cleaning up the JSP's. However, if I can squeeze even a minor, but noticable, difference out of anything in the app I am going to.
Anyway, if no one can come up with a concrete way to measure the actual browser session, I will just go with iterating through the variables. We already have a utility for handling sessions so that is not difficult, just not anymore accurate that anything else I've seen suggested.
Maximilian Xavier Stocker
Joined: Sep 20, 2005
I am a bit confused by your reply. What are you trying to measure exactly? Do you know where the variables are being stored?
A session works like this.
I am the webserver and you are the client.
You come to me and say Hi my name is Rob Aught. Hand you back a unique session id. Let us say your session id is 1.
Then in MY memory (or however I store sessions I have Name=Rob Aught) but YOU (the client only store) sessionid=1
Now if you had a shopping cart and add a product to it then my session information might have (Name=Rob Aught cartitems=1 item1=123ABC) but you as the client still only have sessionid=1
So is this really a session or all stored as client side cookies? If it is the former then the client browser has nothing to do with it... the only overhead is the unique session identifier (which you most likely can't do anything about). If it is the latter then it is all a string so is exactly the length that it appears to be and you can view this in a number of ways.
Maximilian Xavier Stocker
Joined: Sep 20, 2005
I am off for the day but I will leave with you with this advice. Whatever problem you are trying to solve look elsewhere.
Session memory usage is usually not a performance issue. If handled badly enough the server might well crash but performance... I haven't seen much of that. I have again seen plenty of times where mangled session usage kills the webserver and just before it croaks it will get awful slow but that doesn't seem to be what you are describing.
So I would check over the usual culprits... namely DB access points. Make sure you are using an adequately sized connection pool and not doing foolish things like loading more data then you need or repeatedly getting and handing back connections.
That last point in my experience kills more sites for performance and sometimes the whole site itself more than anything else. I once saw an ASP site where connections (not even pooled) were opened and closed 17 times in one page! Ayiyiyiy.
Sorry to get off track there...
if none of this helps then consider describing with a little more detail what problem you are trying to solve. Performance? How much load is the server under when you see this problem? Describe more about your setup. This information will better enable me or someone else to help you step through the problem and resolve it.
I made a JSP that snoops through the session and serializes everything it finds to strings and reports the string sizes. This is definitely NOT the memory size of the objects, but it seemed to be a reasonable approximation of relative sizes and some indicator of change over time. Size became an issue at one point because we persist session state to db and had some problems there.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
If you are having performance issues, it'd be best to invest in a profiling tool to find out where the bottlenecks really are. Shooting in the dark, such as wondering about whether the number of objects mapped into a session are an issue, is unlikely to help much.