James Simpson wrote:
Hello again,
I followed the link you have provided but it has merely shown me reasons
not to use InProc in ASP.NET sessionstates. I am aware that Inproc isn't
practical for many situations, however in the business world this type of
simplicity of Inproc would be required for my web application. Inproc
certainly does have a fair amount of limits, but I need to understand more
about the limits behind Inproc so that I can adjust my solution accordingly.
If someone could please post a site of give me some rough numbers with
regards to the practical limit of concurrent users with InProc sessionstates
and the relative security of using this system. Again, I am aware that there
are far better solutions in most cases, but my web application's situation
isn't like most other cases and really ought to use InProc session states.
Regards,
James Simpson
Straightway Technologies Inc.
Hi James,
Please don't take the following statement the wrong way. You've decided
to use InProc, because you think it meets your needs, so why are you
looking any further?
Okay, slightly more seriously, you aren't going to find somewhere with
any useful numbers. One site running on an old desktop machine with
256M of memory, keeping 2K of information in session will be able to
handle a lot less users than a modern quad Xeon box with Gigs of memory
and only keeping an int in session state.
The only real way to determine what's reasonable is for you to obtain
your production box (or preferably, a test box specced identically);
decide what is acceptable in your (or your users) eyes - i.e. subsecond
response may be required for some projects, in others a wait of tens of
seconds may be deemed acceptable; and either use your system or
simulate the approximate load you anticipate your system will have on
the session. Then ramp up the number of users until response becomes
unacceptable. This really is the only way you'll get the numbers you
want. Anything else will be wild approximations.
Damien
