[hunchentoot-devel] re: thread pool benchmark results

[Anton Vodonosov]

on Monday, August 11, 2008, 3:56:15 PM Nick wrote:

> on Friday, July 18, 2008, 7:34:27 AM Hans wrote:

>> On Fri, Jul 18, 2008 at 03:00, Anton Vodonosov <avodonosov at yandex.ru> wrote:

>>> I have set up a little benchmark to test ithow
>>> thread pool may improve the hunchentoot performance.
>>>
>>> In two words it looks useful. Details are below.
[...]
>> I think we would accept performance patches to the development
>> version.  The revised connection management should make it easier to
>> integrate thread pooling in a portable fashion.

> I used pcall

>    http://marijn.haverbeke.nl/pcall/

> to make a portable thread-pool-powered connection manager
[...]
> anyways I tried to benchmark it against the
> one-thread-per-connection-manager on my laptop using siege. I used
> both the default dispatcher (the default hunchentoot landing page) and
> a dispatcher that returned a handler that slept for 3 seconds and
> returned a page

>    (defun wait-for-3-seconds (hunchentoot:*request*)
>      (lambda () (sleep 3) "this is the page"))

> with 3-5 threads in the pool the 1-thread-per-connection manager
> performed a lot better with both dispatchers. with 20-50 threads both
> connections managers had about the same performance with the
> 1-thread-per-connection manager being slightly faster.

> I'm sure there are better ways to benchmark it, but I'm not in a
> position to be playing with our server at the moment. I haven't taken
> a look at Anton's tests yet.

> Nick

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?

Best regards,
-Anton