[hunchentoot-devel] serious H'toot performance problem on CCL OSX ?

JTK jetmonk at gmail.com
Wed Aug 18 23:53:36 UTC 2010


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












More information about the Tbnl-devel mailing list