From: Thorbjoern Ravn Andersen
The point here is that you CANNOT determine this number
accurately ahead of time, so stating that "only 5000 sessions please"
is bound to either be too low or - worse - too high a number.
It seems to me that a session limit would be roughly analogous to Apache ThreadsPerChild. IIS probably has a comparable setting. One may not know exactly what limit to set to begin with, but experience would be your guide (or, test and measure beforehand, as Walden suggests, if a testing tool supports sessions).
Actually, limiting sessions makes a lot more sense to me than limiting ThreadsPerChild and KeepAliveTimeout because socket connections require such little CPU and memory. But sessions are a different story - we've already established that they often consume a lot of resources.
On the other hand, Apache ThreadsPerChild and KeepAliveTimeout determine the number of pre-fork CGI jobs that may be launched, based on load. To me, that's bad. You may want to limit pre-fork jobs, but not limit sockets and persistent socket connections. An AJAX client may be firing off requests to the server based on keystrokes, for example. You may have a lot of static content. You may need lots of persistent socket connections.
I assume that database servers have limits to client connections (J2EE, PHP, and .Net developers should know more about that than me - I'm an RPG programmer). Part of the reason for this discussion is to let people share their experience with such settings - I bet we all could learn from it. Session Limits? Database Connection Limits? Other settings?
Besides, people tend to dislike those "go away I'm too busy" websites.
Unfortunately, the alternative seems to be some sort of core dump.
OS/400 knows how to adjust itself on-the-fly based on performance
metrics. Are you suggesting we should settle for anything less O:-)
No, I'm not suggesting that. It seems that most web site administrators settle for less, but that's what makes this topic interesting.
Nathan.
midrange.com
