[hunchentoot-devel] re: thread pool benchmark results

[Nick Allen]

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.
> [...]
>> Patch for port-sbcl.lisp with the simple thread pool
>> implementation is also attached. It is against 0.15.7,
>> sorry it's not for the current development version of
>> hunchentoot, but I created this thead pool code about
>> half a year ago.

> 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 (note: I
don't have lispworks and I have no idea if pcall and lispworks work
together since it uses bordeaux threads)

   darcs get http://common-lisp.net/project/bpm/darcs/pcall-connection-manager

I think once the cl.net darcsweb script it might be browsable on the web at

   http://common-lisp.net/cgi-bin/darcsweb/darcsweb.cgi?r=bpm-pcall-connection-manager;a=summary

but I'm not 100% positive and I don't know how long it will take for
it to be visible...

note: in order to use it you have to add &ALLOW-OTHER-KEYS to the end
of the parameters to HUNCHENTOOT:START-SERVER so it will accept the
:CONNECTION-MANAGER-CLASS keyword arg

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