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-...
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
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
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
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
-
Anton Vodonosov -
Nick Allen