Re: session vs request

[Jesse Vitrone]

Thanks for replies all, lots of interesting points, all good to keep in mind. I've googled this, but didn't find anything good.  Is there a good way to find out the size of the session?  Check the size of the session, then run through the app to get app my stuff in the session, then check the size again?  I'd like to be able to serialize it, then check the file size, but if I remember correctly, HttpSession isn't serializeable.  Maybe loop through everything in the session and make a collection of my own objects and serialize that?  Would that give me a good idea, or would that be inaccurate? I can watch the size of Tomcat go up, but that includes all that Hibernate is doing, as well as some other webapps on the same server that mine interact with, so just the straight Tomcat footprint isn't telling me too much. Thanks again for the help,     Jesse Craig McClanahan wrote: On 7/7/05, Jesse Vitrone <[EMAIL PROTECTED]> wrote: Obviously nobody has limitless memory and performance, that's why I'm wondering if there is a rule of thumb for figuring out if it's going to be too much for the server to handle. Is 100 users on a decent sized app going to kill the server if it's all in the session? Is 200? The number of users is not enough information to answer this question. Just to be precise, the measure you want to use is *simultaneous* users, not *total* users. It is only logged on users, after all, that occupy session memory at all (or use any other resources, for that matter). Next, you have to have some sort of estimate of the total bytes of space your session scoped data takes, then (after multiplying by the number of active users) you'll have a number to compare to the total available heap size of your server. Size of session data can be difficult to measure precisely ... for a SWAG measure, figure 20-30 bytes per object, plus the size of all the instance variables. So, 2000 users at 10kb per session = 20mb ... not likely to be a problem on any server. Or, 100 users at 1mb per session = 100mb ... something you can by enough memory to handle, but you need to plan for it. Or, 10 users at 100mb per session = 1gb ... might need to see if your JVM can go that high. The other thing to look at, besides total memory occupancy, is whether caching stuff in the session reduces the amount of database access you need on each request (especially stuff you have to reread because it *wasn't* cached). Depending on the characteristics of your application, this tradeoff could *substantially* improve the overall performance of your application, and be well worth an investment in additional memory. But there is no "average app" that is representative enough of how *your* app will use its resources, any more than there is an "average benchmark" that will tell you which server will run it faster. >>I think also jsf supports both approaches via the ability to store backing info on the client side via config option. That is true, but that only reflects what happens to the component tree for the current view, not anything your application stores for its own use. AND, choosing the "server" option does *not* mean that the component tree will necessarily be kept in the session -- the JSF implementation is free to do whatever it wants, as long as it persists the data in a way that it can be restored. Check the docs on your JSF implementation to know how it handles this, as well as for any tuning parameters that might affect how memory is used. Craig