It is easy to understand why the 3-seconds-sleeping handler made the thread pool inefficient - while threads are sleeping during handling of first few requests, other requests are suspended.
For the cases when so long-running handlers are present, maximum thread count may be unbound - thread pool have number of threads preallocated, but when new request arrives and there is no free thread, new thread is created/added to pool temporary.
What do you mean when you say that you tried the default dispatcher and the sleeping dispatcher? Did you tested them simultaneously, so that sleeping handler blocked the threads?
Or you tested the default dispatcher separately, and thread pool performance was worse? If yes - it is very strange. In this case I'd be interested to know what is your platform, lisp implementation. What is the siege parameters?
um... I mean that I sieged hunchentoot w/ a dispatcher that just returned the default page twice, once with the thread-pool connection manager then once with the one-thread-per-connection manager
then I sieged it twice more (once with the thread pool, once with the one-thread-per..) with the dispatcher that returned a handler that slept then returned the page
SBCL, compiled for multi-threads on Mac OS X 10.4.11 Intel
siege parameters were nothing special
I haven't had time to come back and look at this... am I wrong in assuming that calling SLEEP is somehow fundamentally different than a thread wasting time being blocked on IO?
Nick