I hooked up Lambda-Probe (Psi-Probe) to my Tomcat running a demo Vaadin app today. The app is pretty small and doesn’t use the HttpSession at all.
When I inspect the session counts/size in Probe, all Vaadin sessions have a whopping size of at least 10Mb!
I dig into the session and find out that there is a single object com.vaadin.terminal.gwt.server.WebApplicationContext that takes almost 10MBs in size.
Anybody knows if this is a mistake in Probe or Vaadin session is at least 10Mb?
Thanks
Sounds like a mistake. Please keep this thread updated when you find out what was the cause for the bloated session size.
I found out what the issue is! What a relief!
It turns out that LambdaProbe for some reason gives me the wrong information. And its calculating algorithm drags my PC down to its knee (CPU up 99% while the calculation is carried on).
I have a chance to repeat the same analysis at home tonight. LambdaProbe still shows Vaadin session consumes about 10 - 23 MBs (yes it’s 23 Megabytes).
I search around for a solution and finally found one that can give me the right answer: MessAdmin
http://messadmin.sourceforge.net/
Apparently, calculating HttpSession size is a tricky business!
But any way, base on the documentation of MessAdmin, I use one of their recommendation to calculate session size using the average session size. That brings Vaadin session down to below 200KBs per session. Not a bad number!
Please notice one thing that statistically, the more sessions you create, the more accurate your average get. After 10 sessions, I got 500KBs/session. Over 20 I got 200KBs/Session.
Calculating session sizes is tricky - it would be great to be able to point to a trivial tool for calculating - or even integrating session size calculation to Vaadin debug window somehow.
One note on calculating the average session sizes. You might want to first initialize handful of sessions - say 10 - and then take the total session size - call it X. The “average” X/10 probably includes a lot of overhead. Then initiate Y more sessions (rising the total to 10 + Y) and take the total session size - call it Z. I would argue that the most meaningful way of calculating the average session size would be as (Z-X)/Y. The first 10 sessions do not matter - the next 10.000 do.
There are two ways of calculating the session size:
Joonas, what you are saying is method #2 and I think it should give you a more accurate number.
Doug
Apologies to revive an old thread, just didn’t think I should post a new one. I’m also using MessAdmin, but under Glassfish 3.1 (as I use EJB3.1). My web app is quite simple at the moment, just a few entity management screens (with tables and paginations, all lazily instantiated - using lazy query container etc etc.). All my Panels/Layouts are only drawn on ‘attach’ so the whole application doesn’t instantiate a million objects - just what is needed for the current view. There are 3 tabs, each with it’s own menu. Not big! However, my session size is around 100Mb, and this is just after login. However, I think I am reading it wrong.
The first image (after-login)
org.jboss.weld.context.http.HttpSessionContext: 100.68Mb
com.vaadin.terminal.gwt.server.WebApplicationContext: 100.66Mb
Is the session size: (100.68 megabytes) - (100.66 megabytes) = 20.48 kilobytes ?
After using the site for a bit, paginating through a few things, the sizes become:
org.jboss.weld.context.http.HttpSessionContext: 100.7Mb
com.vaadin.terminal.gwt.server.WebApplicationContext: 100.66Mb
So, is the session size: (100.70 megabytes) - (100.66 megabytes) = 40.96 kilobytes?
I guess my concern is, is the 100.66Mb base footprint ‘fixed’ per WAR file deployment - or is it going to be allocated for all new sessions? If the latter, I’ll be doing some soul searching. No screen I’ve made could possibly be 100Mb! My EAR file is only 11Mb 
But I could be very wrong.
Not content with my earlier diagnosis, I set out to write a button that would serialise my ‘application’ to disk.
public void writeSession() {
try {
// use buffering
OutputStream file = new FileOutputStream("session.ser");
OutputStream buffer = new BufferedOutputStream(file);
ObjectOutput output = new ObjectOutputStream(buffer);
try {
// 'this' is the application class instance
output.writeObject(this);
} finally {
output.close();
}
} catch (IOException ex) {
ex.printStackTrace();
}
}
The result is:
-rw-r--r-- 1 prguser staff 24086 10 Jul 21:24 session.serand after doing some more clicking around to other tabs/menus:
-rw-r--r-- 1 prguser staff 38398 10 Jul 21:28 session.serSo, approx. 24Kb. to 40kb. I know that this is not definitive, but it looks a lot better than 100+ Mb. Can anyone confirm that this is the way that are getting their session sizes?
Thanks
This sounds quite normal - having large tables etc. can increase the memory usage somewhat, and of course your own data kept in memory will have to be added to the session size, but session sizes of tens of kilobytes or perhaps a hundred kilobytes are in the range I would expect. At your session sizes, each gigabyte of heap could hold 25000-40000 sessions.
As for measuring with the difference method, the first session will certainly trigger loading a lot of other things on the server, and so can the next few. Therefore, if using the difference method, you should e.g. first start several sessions, and then take the average size increase of the next 10+ after them.
Also note that when serializing just one session, it is possible that some objects that can be shared between sessions also get included, depending on if your session has pointers to some static data structures etc. Therefore, the size you are getting might overestimate the true size somewhat.
Thanks for your clear answer. Yes 20-40Kb is excellent, even 500kb is more than good enough for the traffic I expect on the server we’ll be deploying on (several hundred sessions max - any more and we’re doing quite well!). I’m surprised to see that the usage is actually quite so low.
I’m very happy with that result, and Vaadin of course!