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