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
