msession tech note, "feature" (buglet), call for suggestions.

I will compose a much better version of this and put it my white paper, but for those of you looking at msession, there is a poorly described option that will affect performance badly. The msession daemon is a 1 thread per connection server. This means that only [n] concurrent PHP sessions can be active at any one time. (n being the number of threads). I may redesign this in the future, as the threads spend much of their time waiting. However, for now, upping the number of threads fixes a problem reported today to Mohawk Software. It isn't a "bug," exactly. It is a misunderstanding about a feature and a very poor default number of threads. Depending on the ratio of the number of Apache processes who require PHP session information, and those which serve static content (or don't use session variables), you should adjust the number of threads to the msession daemon. If you run something like Oracle or PostgreSQL, take a look at the number of processes that are active, and set the number of msession threads to something like that. Many users will never see this problem, as msession is pretty fast. When this is seen is when PHP is talking to an application server like a database or a search engine. The length of time the PHP script has the session socket open, that thread in msession is waiting. If you only have 4 msession threads, it is easy to see you will have all your service threads sitting around doing nothing. Poof, there goes performance. The reasons it was done like this are historical. It was originally a shared data system for a beowulf cluster, the active connection was to implement global mutexes. While the system has been completely rewritten, the old thread model remains. There are a number of ways to deal with this, but creating a socket pool of active sockets, and have a number of threads handle the sockets in a classing queue fashion seems like the best way. Anyone have a better idea?