I had this problem a while back (with a pre-1.0 Hunchentoot on SBCL 10.0.20 on a couple of elderly dual Opterons). I was able to deal with it by having a proxy server in front of Hunchentoot limit the number of connections it'd make to the Hunchentoot backends at any one time, which worked acceptably, and allowed for well over 200 requests per second (where the content being loaded from cache; realistic usage scenarios were somewhat below this due to app logic etc.) Rob
On 19 August 2010 00:53, JTK jetmonk@gmail.com wrote:
Hello,
I'm finding that the speed of hunchentoot falls drastically for more than 1 simultaneous connection, at least for CCL on OS X. And more than a few connections just fails.
I downloaded the latest svn version from http://bknr.net/html/
To reduce any complicating factors, I loaded just h'toot and ran ccl on the shell command line, not in slime.
I tried a simple page:
CL-USER> (hunchentoot:start (make-instance 'hunchentoot:acceptor :port 4242)) #<ACCEPTOR (host *, port 4242)> CL-USER> (hunchentoot:define-easy-handler (say-yo :uri "/yo") () (setf (hunchentoot:content-type*) "text/plain") "Yo! This. Is. Content") SAY-YO
Then I tried the ab (apache bench) benchmark with c=1 (1 connection), and 500 iterations:
$ ab -n 500 -c 1 http://127.0.0.1:4242/yo
HTML transferred: 10500 bytes Requests per second: 138.26 [#/sec] (mean) <- ##### note speed ###### Time per request: 7.233 [ms] (mean) Time per request: 7.233 [ms] (mean, across all concurrent requests) Transfer rate: 22.82 [Kbytes/sec] received
Then I tried it with TWO concurrent connections:
$ ab -n 500 -c 2 http://127.0.0.1:4242/yo
HTML transferred: 10500 bytes Requests per second: 29.10 [#/sec] (mean) <- ##### note speed ###### Time per request: 68.722 [ms] (mean) Time per request: 34.361 [ms] (mean, across all concurrent requests) Transfer rate: 4.80 [Kbytes/sec] received
It's nearly 5x slower with just 2 simultaneous connections, going from 138 to 34 requests/sec.
10 connections gives the same speed as 2, and 30 fails because connection was reset by peer (maybe my fault for not having enough open files available, but it should never open more than 30 filehandles at once, no?).
I'm running on a Mac OS X 10.6 with CCL "Version 1.4-r13119 (DarwinX8664)"
Can anyone else reproduce this? Is it some threading problem?
John
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel