[hunchentoot-devel] re: thread pool benchmark results

[Nick Allen]

> 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