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
Hi John,
we are using hunchentoot for a while in our application and made a similar experience. We're using it with SBCL on ubuntu and MAC systems.
Another problem that we are currently debugging is that the needed memory on two or more parallel requests is not released, so the machine stops working when there is no RAM available. But at the moment we are not sure if this problem is 100% caused by hunchentoot.
Best regards
lukas
-------------------------------------------------- From: "JTK" jetmonk@gmail.com Sent: Thursday, August 19, 2010 1:53 AM To: tbnl-devel@common-lisp.net Subject: [hunchentoot-devel] serious H'toot performance problem on CCL OSX ?
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
John,
what you are seeing is probably related to the fact that the default multi threaded task master of Hunchentoot is not clever about creating threads. It creates a new thread for every incoming connection, so it is easy to force it into situations where too many threads are created.
Personally, I am not using multi threaded Hunchentoot. Instead, I run it single threaded and behind a HTTP caching proxy (squid) that is configured to use if-modified-since headers to negotiate reloading stuff from the Hunchentoot backend. That strategy works well and copes with all load patterns that I have tried (and I have tried a few, using both ab and Tsung).
If you absolutely need threads, try the threading patch that has been submitted by Scott McKay a few weeks ago. It prevents Hunchentoot from creating threads without bounds, and might solve the problem for you. We will be incorporating that patch once it has been separated from the xcvb changes that won't go into the Hunchentoot mainline. Any reports on how it helps with artificial loads tests would be appreciated.
For the SBCL crash: This should be reported to the SBCL folks. I never had a lot of faith in SBCL's thread implementation and it also is possible that the locking patterns inside of Hunchentoot trigger the misbehavior, but we need to have detailed advise how to fix that, if we need to.
-Hans
On Thu, Aug 19, 2010 at 01: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
On Aug 18, 2010, at 10:11 PM, Hans Hübner wrote:
John,
what you are seeing is probably related to the fact that the default multi threaded task master of Hunchentoot is not clever about creating threads. It creates a new thread for every incoming connection, so it is easy to force it into situations where too many threads are created.
Personally, I am not using multi threaded Hunchentoot. Instead, I run it single threaded and behind a HTTP caching proxy (squid) that is configured to use if-modified-since headers to negotiate reloading stuff from the Hunchentoot backend. That strategy works well and copes with all load patterns that I have tried (and I have tried a few, using both ab and Tsung).
If you absolutely need threads, try the threading patch that has been submitted by Scott McKay a few weeks ago. It prevents Hunchentoot from creating threads without bounds, and might solve the problem for you. We will be incorporating that patch once it has been separated from the xcvb changes that won't go into the Hunchentoot mainline. Any reports on how it helps with artificial loads tests would be appreciated.
Here's a simple webserver that avoids H'toot altogether. It has a thread manager (make-safe-process) that avoids making too many threads at once. The threshold *max-procs* is very low and it never seems to hit the limit (because it prints warnings when it does).
If you run it as (do-dumb-server-loop :port NNNN) it runs great with just one request at a time, but fails with more than one thread (just like H'toot). Moreover, even in single-connection mode, the server performance deteriorates as one does more runs.
So it almost looks to me that CCL threads on the the mac might be broken somehow.
;; =========================================== ;; simple threaded webserver to exercise threads and sockets
(eval-when (load eval compile) (require 'bordeaux-threads) (require 'usocket))
(defparameter *lock* (bt:make-recursive-lock "proc-lock")) (defparameter *max-procs* 10) ;; max number of threads we allow
(let ((nprocs 0)) ;; counter for how many threads are running (defun safe-make-process (func) "A function that launches FUNC in a new thread only if there are not more than *MAX-PROCS* running; otherwise it sleeps for a bit" (bt:with-lock-held (*lock*) (format t "Making proc with ~A already existing~%" nprocs) (force-output)) ;; sleep until some processes die (loop while (bt:with-lock-held (*lock*) (> nprocs *max-procs*)) do (format t "Warning - nprocs=~A~%" nprocs) (force-output) (sleep 0.1)) ;; (bt:with-lock-held (*lock*) (incf nprocs)) (bt:make-thread (lambda () (unwind-protect ;; protect the decrement of the counter (funcall func) (bt:with-lock-held (*lock*) (decf nprocs)))))))
(defun do-dumb-server-loop (&key (port 9001)) (loop with listener = (usocket:socket-listen "127.0.0.1" port) for sock = (usocket:socket-accept listener) when sock do (safe-make-process (lambda () ;; I think we need to close over sock here or this thread's ;; loop might change what REPLY-FUNC sees (let ((this-sock sock)) (reply-func this-sock))) )))
(defparameter *response* "HTTP/1.1 200 OK Server: dumb Connection: Close Content-Type: text/plain
This is the content. ")
(defun reply-func (sock) ;; read headers and send content (let ((s (usocket:socket-stream sock))) (ignore-errors ;; eat client headers (loop for line = (read-line s nil nil) until (< (length line) 3)) ;; and send response (write-string *response* s)) ;; the socket close is protected by ignore-errors (usocket:socket-close sock)))
;; ===========================================
For the SBCL crash: This should be reported to the SBCL folks. I never had a lot of faith in SBCL's thread implementation and it also is possible that the locking patterns inside of Hunchentoot trigger the misbehavior, but we need to have detailed advise how to fix that, if we need to.
-Hans
On Thu, Aug 19, 2010 at 01: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
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
John,
I have made a few experiments with your test server on my FreeBSD box using ccl-1.5. I had to adjust the backlog parameter in usocket:socket-listen so that could cope with higher concurrency values, but other than that, I could see nothing abnormal.
Before going to the CCL mailing list with your problem, consider upgrading CCL to a more recent version.
-Hans
On Thu, Aug 19, 2010 at 12:27, JTK jetmonk@gmail.com wrote:
On Aug 18, 2010, at 10:11 PM, Hans Hübner wrote:
John,
what you are seeing is probably related to the fact that the default multi threaded task master of Hunchentoot is not clever about creating threads. It creates a new thread for every incoming connection, so it is easy to force it into situations where too many threads are created.
Personally, I am not using multi threaded Hunchentoot. Instead, I run it single threaded and behind a HTTP caching proxy (squid) that is configured to use if-modified-since headers to negotiate reloading stuff from the Hunchentoot backend. That strategy works well and copes with all load patterns that I have tried (and I have tried a few, using both ab and Tsung).
If you absolutely need threads, try the threading patch that has been submitted by Scott McKay a few weeks ago. It prevents Hunchentoot from creating threads without bounds, and might solve the problem for you. We will be incorporating that patch once it has been separated from the xcvb changes that won't go into the Hunchentoot mainline. Any reports on how it helps with artificial loads tests would be appreciated.
Here's a simple webserver that avoids H'toot altogether. It has a thread manager (make-safe-process) that avoids making too many threads at once. The threshold *max-procs* is very low and it never seems to hit the limit (because it prints warnings when it does).
If you run it as (do-dumb-server-loop :port NNNN) it runs great with just one request at a time, but fails with more than one thread (just like H'toot). Moreover, even in single-connection mode, the server performance deteriorates as one does more runs.
So it almost looks to me that CCL threads on the the mac might be broken somehow.
;; =========================================== ;; simple threaded webserver to exercise threads and sockets
(eval-when (load eval compile) (require 'bordeaux-threads) (require 'usocket))
(defparameter *lock* (bt:make-recursive-lock "proc-lock")) (defparameter *max-procs* 10) ;; max number of threads we allow
(let ((nprocs 0)) ;; counter for how many threads are running (defun safe-make-process (func) "A function that launches FUNC in a new thread only if there are not more than *MAX-PROCS* running; otherwise it sleeps for a bit" (bt:with-lock-held (*lock*) (format t "Making proc with ~A already existing~%" nprocs) (force-output)) ;; sleep until some processes die (loop while (bt:with-lock-held (*lock*) (> nprocs *max-procs*)) do (format t "Warning - nprocs=~A~%" nprocs) (force-output) (sleep 0.1)) ;; (bt:with-lock-held (*lock*) (incf nprocs)) (bt:make-thread (lambda () (unwind-protect ;; protect the decrement of the counter (funcall func) (bt:with-lock-held (*lock*) (decf nprocs)))))))
(defun do-dumb-server-loop (&key (port 9001)) (loop with listener = (usocket:socket-listen "127.0.0.1" port) for sock = (usocket:socket-accept listener) when sock do (safe-make-process (lambda () ;; I think we need to close over sock here or this thread's ;; loop might change what REPLY-FUNC sees (let ((this-sock sock)) (reply-func this-sock))) )))
(defparameter *response* "HTTP/1.1 200 OK Server: dumb Connection: Close Content-Type: text/plain
This is the content. ")
(defun reply-func (sock) ;; read headers and send content (let ((s (usocket:socket-stream sock))) (ignore-errors ;; eat client headers (loop for line = (read-line s nil nil) until (< (length line) 3)) ;; and send response (write-string *response* s)) ;; the socket close is protected by ignore-errors (usocket:socket-close sock)))
;; ===========================================
For the SBCL crash: This should be reported to the SBCL folks. I never had a lot of faith in SBCL's thread implementation and it also is possible that the locking patterns inside of Hunchentoot trigger the misbehavior, but we need to have detailed advise how to fix that, if we need to.
-Hans
On Thu, Aug 19, 2010 at 01: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
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
I have the following situation with http://lisper.ru/ (Hunchentoot + SBCL on Debian VPS without Apache, nginx, etc.)
$ /usr/sbin/ab -n 100 -c 1 http://lisper.ru/
HTML transferred: 531200 bytes Requests per second: 153.37 [#/sec] (mean) Time per request: 6.520 [ms] (mean) Time per request: 6.520 [ms] (mean, across all concurrent requests) Transfer rate: 817.95 [Kbytes/sec] received
$ /usr/sbin/ab -n 100 -c 10 http://lisper.ru/
HTML transferred: 531200 bytes Requests per second: 157.23 [#/sec] (mean) Time per request: 63.600 [ms] (mean) Time per request: 6.360 [ms] (mean, across all concurrent requests) Transfer rate: 838.52 [Kbytes/sec] received
$ /usr/sbin/ab -n 100 -c 20 http://lisper.ru/
HTML transferred: 531200 bytes Requests per second: 67.39 [#/sec] (mean) Time per request: 296.800 [ms] (mean) Time per request: 14.840 [ms] (mean, across all concurrent requests) Transfer rate: 359.37 [Kbytes/sec] received
$ /usr/sbin/ab -n 100 -c 50 http://lisper.ru/
HTML transferred: 531200 bytes Requests per second: 33.11 [#/sec] (mean) Time per request: 1510.000 [ms] (mean) Time per request: 30.200 [ms] (mean, across all concurrent requests) Transfer rate: 176.59 [Kbytes/sec] received
I believe that a significant decrease in performance when the number of requests for more than 10 due to the limited resources of VPS. On my working machine (Gentoo) performance degradation with increasing number of requests is much smaller.
Andrey
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
I am not seeing it Hunchentoot 1.1.0 (2010-01-08) OS X 10.6.4
Stix:ccl wade$ uname -a Darwin Stix.local 10.4.0 Darwin Kernel Version 10.4.0: Fri Apr 23 18:28:53 PDT 2010; root:xnu-1504.7.4~1/RELEASE_I386 i386 Stix:ccl wade$ ./dx86cl64 ; loading system definition from ccl:tools;asdf-install;asdf-install.asd.newest into #<Package "ASDF0"> ; registering #<SYSTEM ASDF-INSTALL #x3020005AD22D> as ASDF-INSTALL ;;; ASDF-Install version 0.6.10 Welcome to Clozure Common Lisp Version 1.5-r13952M (DarwinX8664)! ? (quit)
Stix:ccl wade$ ab -n 500 -c 1 http://127.0.0.1:4242/yo This is ApacheBench, Version 2.3 <$Revision: 655654 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking 127.0.0.1 (be patient) Completed 100 requests Completed 200 requests Completed 300 requests Completed 400 requests Completed 500 requests Finished 500 requests
Server Software: Hunchentoot Server Hostname: 127.0.0.1 Server Port: 4242
Document Path: /yo Document Length: 21 bytes
Concurrency Level: 1 Time taken for tests: 0.991 seconds Complete requests: 500 Failed requests: 0 Write errors: 0 Total transferred: 84500 bytes HTML transferred: 10500 bytes Requests per second: 504.66 [#/sec] (mean) Time per request: 1.982 [ms] (mean) Time per request: 1.982 [ms] (mean, across all concurrent requests) Transfer rate: 83.29 [Kbytes/sec] received
Connection Times (ms) min mean[+/-sd] median max Connect: 0 0 0.0 0 0 Processing: 1 2 1.2 2 10 Waiting: 1 2 1.2 2 10 Total: 1 2 1.2 2 10
Percentage of the requests served within a certain time (ms) 50% 2 66% 2 75% 2 80% 2 90% 2 95% 6 98% 6 99% 6 100% 10 (longest request)
Stix:ccl wade$ ab -n 500 -c 2 http://127.0.0.1:4242/yo This is ApacheBench, Version 2.3 <$Revision: 655654 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking 127.0.0.1 (be patient) Completed 100 requests Completed 200 requests Completed 300 requests Completed 400 requests Completed 500 requests Finished 500 requests
Server Software: Hunchentoot Server Hostname: 127.0.0.1 Server Port: 4242
Document Path: /yo Document Length: 21 bytes
Concurrency Level: 2 Time taken for tests: 0.655 seconds Complete requests: 500 Failed requests: 0 Write errors: 0 Total transferred: 84500 bytes HTML transferred: 10500 bytes Requests per second: 762.88 [#/sec] (mean) Time per request: 2.622 [ms] (mean) Time per request: 1.311 [ms] (mean, across all concurrent requests) Transfer rate: 125.91 [Kbytes/sec] received
Connection Times (ms) min mean[+/-sd] median max Connect: 0 0 0.1 0 1 Processing: 1 2 1.7 2 14 Waiting: 0 2 1.7 2 14 Total: 1 3 1.7 2 14
Percentage of the requests served within a certain time (ms) 50% 2 66% 2 75% 2 80% 2 90% 6 95% 7 98% 7 99% 7 100% 14 (longest request) Stix:ccl wade$
On Aug 19, 2010, at 8:03 AM, Wade Humeniuk wrote:
I am not seeing it Hunchentoot 1.1.0 (2010-01-08) OS X 10.6.4 ...
[Summary: Wade is getting 500+ req/sec for both 1 and 2 connections for 64 bit CCL 1.5 on OS X]
Thank you for looking into it, Wade (and Hans, Andrey, and Robert)
Following Hans' suggestion I upgraded to CCL 1.5. I tried using both release and trunk. This helped a bit; 2 concurrent requests now work.
To be safe, I rebuilt all of H'toot from the bknr SVN tree, just in case I missed anything the first time.
I'm running on the latest i7 Macbook Pro, so I think I should be getting speeds near the top of Wade's range. From tcsh 'limit', my descriptors limit is 4864 and maxproc is 256
Some tests, with abbreviated outputs, are appended below, as is my dumb-server.lisp code for comparison.
First, the conclusions:
* Replacing CCL 1.4 with 1.5 allows concurrency to work in H'toot better but not very well. concurrency=2 works, but not 10.
* H'toot is running 4x to 10x slower for me than for Wade, yet we're both using 64 bit CCL 1.5 with Darwin Kernel Version 10.4.0, Apache Bench 2.3. I tried both the release CCL 1.5 and the latest trunk.
* My dumb server with bordeaux threads and usocket is running at 1200 req/sec, 10x faster than my H'toot and 2x Wade's H'toot speed. The dumb server works at a concurrency of 10, unlike H'toot.
* My dumb server using raw CCL sockets and threads runs about as fast as the bordeaux+usocket version, so bordeaux and usocket seem fine.
Wade, could I ask one more favor, even though you've already helped a lot? Could you please run my (do-dumb-server-loop :port 4001) and benchmark it on your Mac? I'm curious if it will be 5x faster on yours, like H'toot was. I'm getting about 1200 requests/sec.
Thanks, John
;; ###################### ;; run H'toot /yo page as before with 1 connection $ ab -n 500 -c 1 http://127.0.0.1:4000/yo Requests per second: 136.94 [#/sec] (mean) <= #### 4x slower than Wade ##### Time per request: 7.303 [ms] (mean) Time per request: 7.303 [ms] (mean, across all concurrent requests) Transfer rate: 22.60 [Kbytes/sec] received
;; run H'toot with 2 connections $ ab -n 500 -c 2 http://127.0.0.1:4000/yo Requests per second: 46.11 [#/sec] (mean) <= #### 20x slower than Wade ##### Time per request: 43.379 [ms] (mean) Time per request: 21.689 [ms] (mean, across all concurrent requests) Transfer rate: 7.61 [Kbytes/sec] received
;; run H'toot with 10 connections - FAILS $ ab -n 500 -c 10 http://127.0.0.1:4000/yo Benchmarking 127.0.0.1 (be patient) Completed 100 requests Completed 200 requests Completed 300 requests apr_socket_recv: Connection reset by peer (54) Total of 358 requests completed
;; ###################### ;; run my dumb server (see appended code) using bordeaux threads and usocket ;; this prevents more than 20 threads from running at once. It prints a warning if ;; happened, but the limit was never reached
CCL> (do-dumb-server-loop :port 4001)
;; concurrency=1 $ ab -n 500 -c 1 http://127.0.0.1:4000/yo Concurrency Level: 1 Time taken for tests: 0.355 seconds Complete requests: 500 Failed requests: 0 Write errors: 0 Total transferred: 47000 bytes HTML transferred: 10500 bytes Requests per second: 1406.64 [#/sec] (mean) Time per request: 0.711 [ms] (mean) Time per request: 0.711 [ms] (mean, across all concurrent requests) Transfer rate: 129.12 [Kbytes/sec] received
;; concurrency=2 $ ab -n 500 -c 2 http://127.0.0.1:4000/yo Concurrency Level: 2 Time taken for tests: 0.386 seconds Complete requests: 500 Failed requests: 2 (Connect: 0, Receive: 0, Length: 2, Exceptions: 0) Write errors: 0 Total transferred: 46812 bytes HTML transferred: 10458 bytes Requests per second: 1295.73 [#/sec] (mean) Time per request: 1.544 [ms] (mean) Time per request: 0.772 [ms] (mean, across all concurrent requests) Transfer rate: 118.47 [Kbytes/sec] received
;; concurrency=10 $ ab -n 500 -c 10 http://127.0.0.1:4000/yo Concurrency Level: 10 Time taken for tests: 0.483 seconds Complete requests: 500 Failed requests: 5 (Connect: 0, Receive: 0, Length: 5, Exceptions: 0) Write errors: 0 Total transferred: 46530 bytes HTML transferred: 10395 bytes Requests per second: 1034.68 [#/sec] (mean) Time per request: 9.665 [ms] (mean) Time per request: 0.966 [ms] (mean, across all concurrent requests) Transfer rate: 94.03 [Kbytes/sec] received
;; now run a version of dumb server that uses native CCL threads and sockets CCL> (do-dumb-server-loop/ccl :port 4001)
;; concurrency=1 $ ab -n 500 -c 1 http://127.0.0.1:4000/yo oncurrency Level: 1 Time taken for tests: 0.401 seconds Complete requests: 500 Failed requests: 0 Write errors: 0 Total transferred: 47000 bytes HTML transferred: 10500 bytes Requests per second: 1245.62 [#/sec] (mean) <== #### FAST ##### Time per request: 0.803 [ms] (mean) Time per request: 0.803 [ms] (mean, across all concurrent requests) Transfer rate: 114.34 [Kbytes/sec] received
;; concurrency=2 $ ab -n 500 -c 2 http://127.0.0.1:4000/yo Concurrency Level: 2 Time taken for tests: 0.576 seconds Complete requests: 500 Failed requests: 2 (Connect: 0, Receive: 0, Length: 2, Exceptions: 0) Write errors: 0 Total transferred: 46812 bytes HTML transferred: 10458 bytes Requests per second: 867.85 [#/sec] (mean) <== #### FAST, but some errors ##### Time per request: 2.305 [ms] (mean) Time per request: 1.152 [ms] (mean, across all concurrent requests) Transfer rate: 79.35 [Kbytes/sec] received
;; concurrency=10 - $ ab -n 500 -c 10 of http://127.0.0.1:4000/yo Concurrency Level: 10 Time taken for tests: 0.309 seconds Complete requests: 500 Failed requests: 2 (Connect: 0, Receive: 0, Length: 2, Exceptions: 0) Write errors: 0 Total transferred: 46812 bytes HTML transferred: 10458 bytes Requests per second: 1617.78 [#/sec] (mean) <== #### FAST, but some errors ##### Time per request: 6.181 [ms] (mean) Time per request: 0.618 [ms] (mean, across all concurrent requests) Transfer rate: 147.91 [Kbytes/sec] received
Stix:ccl wade$ uname -a Darwin Stix.local 10.4.0 Darwin Kernel Version 10.4.0: Fri Apr 23 18:28:53 PDT 2010; root:xnu-1504.7.4~1/RELEASE_I386 i386 Stix:ccl wade$ ./dx86cl64 ; loading system definition from ccl:tools;asdf-install;asdf-install.asd.newest into #<Package "ASDF0"> ; registering #<SYSTEM ASDF-INSTALL #x3020005AD22D> as ASDF-INSTALL ;;; ASDF-Install version 0.6.10 Welcome to Clozure Common Lisp Version 1.5-r13952M (DarwinX8664)! ? (quit)
Stix:ccl wade$ ab -n 500 -c 1 http://127.0.0.1:4242/yo This is ApacheBench, Version 2.3 <$Revision: 655654 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking 127.0.0.1 (be patient) Completed 100 requests Completed 200 requests Completed 300 requests Completed 400 requests Completed 500 requests Finished 500 requests
Server Software: Hunchentoot Server Hostname: 127.0.0.1 Server Port: 4242
Document Path: /yo Document Length: 21 bytes
Concurrency Level: 1 Time taken for tests: 0.991 seconds Complete requests: 500 Failed requests: 0 Write errors: 0 Total transferred: 84500 bytes HTML transferred: 10500 bytes Requests per second: 504.66 [#/sec] (mean) Time per request: 1.982 [ms] (mean) Time per request: 1.982 [ms] (mean, across all concurrent requests) Transfer rate: 83.29 [Kbytes/sec] received
Connection Times (ms) min mean[+/-sd] median max Connect: 0 0 0.0 0 0 Processing: 1 2 1.2 2 10 Waiting: 1 2 1.2 2 10 Total: 1 2 1.2 2 10
Percentage of the requests served within a certain time (ms) 50% 2 66% 2 75% 2 80% 2 90% 2 95% 6 98% 6 99% 6 100% 10 (longest request)
Stix:ccl wade$ ab -n 500 -c 2 http://127.0.0.1:4242/yo This is ApacheBench, Version 2.3 <$Revision: 655654 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking 127.0.0.1 (be patient) Completed 100 requests Completed 200 requests Completed 300 requests Completed 400 requests Completed 500 requests Finished 500 requests
Server Software: Hunchentoot Server Hostname: 127.0.0.1 Server Port: 4242
Document Path: /yo Document Length: 21 bytes
Concurrency Level: 2 Time taken for tests: 0.655 seconds Complete requests: 500 Failed requests: 0 Write errors: 0 Total transferred: 84500 bytes HTML transferred: 10500 bytes Requests per second: 762.88 [#/sec] (mean) Time per request: 2.622 [ms] (mean) Time per request: 1.311 [ms] (mean, across all concurrent requests) Transfer rate: 125.91 [Kbytes/sec] received
Connection Times (ms) min mean[+/-sd] median max Connect: 0 0 0.1 0 1 Processing: 1 2 1.7 2 14 Waiting: 0 2 1.7 2 14 Total: 1 3 1.7 2 14
Percentage of the requests served within a certain time (ms) 50% 2 66% 2 75% 2 80% 2 90% 6 95% 7 98% 7 99% 7 100% 14 (longest request) Stix:ccl wade$
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
I am running a MacBook Pro (about 4 years old). Core 2 ~2.1 GHz
I get no errors in any run.
Seems to run the same no matter what test I do,
CL-USER> (do-dumb-server-loop :port 4001)
Stix:~ wade$ ab -n 500 -c 1 http://127.0.0.1:4001/yo This is ApacheBench, Version 2.3 <$Revision: 655654 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking 127.0.0.1 (be patient) Completed 100 requests Completed 200 requests Completed 300 requests Completed 400 requests Completed 500 requests Finished 500 requests
Server Software: dumb Server Hostname: 127.0.0.1 Server Port: 4001
Document Path: /yo Document Length: 21 bytes
Concurrency Level: 1 Time taken for tests: 0.599 seconds Complete requests: 500 Failed requests: 0 Write errors: 0 Total transferred: 47000 bytes HTML transferred: 10500 bytes Requests per second: 835.27 [#/sec] (mean) Time per request: 1.197 [ms] (mean) Time per request: 1.197 [ms] (mean, across all concurrent requests) Transfer rate: 76.67 [Kbytes/sec] received
Connection Times (ms) min mean[+/-sd] median max Connect: 0 0 0.0 0 1 Processing: 1 1 0.8 1 5 Waiting: 1 1 0.8 1 5 Total: 1 1 0.8 1 5
Percentage of the requests served within a certain time (ms) 50% 1 66% 1 75% 1 80% 1 90% 1 95% 4 98% 4 99% 4 100% 5 (longest request) Stix:~ wade$ ab -n 500 -c 2 http://127.0.0.1:4001/yo This is ApacheBench, Version 2.3 <$Revision: 655654 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking 127.0.0.1 (be patient) Completed 100 requests Completed 200 requests Completed 300 requests Completed 400 requests Completed 500 requests Finished 500 requests
Server Software: dumb Server Hostname: 127.0.0.1 Server Port: 4001
Document Path: /yo Document Length: 21 bytes
Concurrency Level: 2 Time taken for tests: 0.785 seconds Complete requests: 500 Failed requests: 3 (Connect: 0, Receive: 0, Length: 3, Exceptions: 0) Write errors: 0 Total transferred: 46718 bytes HTML transferred: 10437 bytes Requests per second: 637.18 [#/sec] (mean) Time per request: 3.139 [ms] (mean) Time per request: 1.569 [ms] (mean, across all concurrent requests) Transfer rate: 58.14 [Kbytes/sec] received
Connection Times (ms) min mean[+/-sd] median max Connect: 0 0 0.0 0 0 Processing: 0 3 21.5 1 330 Waiting: 0 1 0.8 1 5 Total: 0 3 21.5 1 331
Percentage of the requests served within a certain time (ms) 50% 1 66% 1 75% 1 80% 1 90% 1 95% 4 98% 4 99% 5 100% 331 (longest request) Stix:~ wade$ ab -n 500 -c 10 http://127.0.0.1:4001/yo This is ApacheBench, Version 2.3 <$Revision: 655654 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking 127.0.0.1 (be patient) Completed 100 requests Completed 200 requests Completed 300 requests Completed 400 requests Completed 500 requests Finished 500 requests
Server Software: dumb Server Hostname: 127.0.0.1 Server Port: 4001
Document Path: /yo Document Length: 21 bytes
Concurrency Level: 10 Time taken for tests: 0.679 seconds Complete requests: 500 Failed requests: 22 (Connect: 0, Receive: 0, Length: 22, Exceptions: 0) Write errors: 0 Total transferred: 44932 bytes HTML transferred: 10038 bytes Requests per second: 735.92 [#/sec] (mean) Time per request: 13.588 [ms] (mean) Time per request: 1.359 [ms] (mean, across all concurrent requests) Transfer rate: 64.58 [Kbytes/sec] received
Connection Times (ms) min mean[+/-sd] median max Connect: 0 0 0.1 0 1 Processing: 0 13 59.5 1 337 Waiting: 0 2 1.8 1 10 Total: 0 13 59.5 1 337
Percentage of the requests served within a certain time (ms) 50% 1 66% 1 75% 1 80% 4 90% 6 95% 9 98% 327 99% 330 100% 337 (longest request) Stix:~ wade$
CL-USER> (do-dumb-server-loop/ccl :port 4001)
Stix:~ wade$ ab -n 500 -c 1 http://127.0.0.1:4001/yo This is ApacheBench, Version 2.3 <$Revision: 655654 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking 127.0.0.1 (be patient) Completed 100 requests Completed 200 requests Completed 300 requests Completed 400 requests Completed 500 requests Finished 500 requests
Server Software: dumb Server Hostname: 127.0.0.1 Server Port: 4001
Document Path: /yo Document Length: 21 bytes
Concurrency Level: 1 Time taken for tests: 0.590 seconds Complete requests: 500 Failed requests: 0 Write errors: 0 Total transferred: 47000 bytes HTML transferred: 10500 bytes Requests per second: 847.87 [#/sec] (mean) Time per request: 1.179 [ms] (mean) Time per request: 1.179 [ms] (mean, across all concurrent requests) Transfer rate: 77.83 [Kbytes/sec] received
Connection Times (ms) min mean[+/-sd] median max Connect: 0 0 0.0 0 0 Processing: 1 1 0.8 1 5 Waiting: 1 1 0.8 1 5 Total: 1 1 0.8 1 5
Percentage of the requests served within a certain time (ms) 50% 1 66% 1 75% 1 80% 1 90% 1 95% 4 98% 4 99% 5 100% 5 (longest request) Stix:~ wade$ ab -n 500 -c 2 http://127.0.0.1:4001/yo This is ApacheBench, Version 2.3 <$Revision: 655654 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking 127.0.0.1 (be patient) Completed 100 requests Completed 200 requests Completed 300 requests Completed 400 requests Completed 500 requests Finished 500 requests
Server Software: dumb Server Hostname: 127.0.0.1 Server Port: 4001
Document Path: /yo Document Length: 21 bytes
Concurrency Level: 2 Time taken for tests: 0.738 seconds Complete requests: 500 Failed requests: 3 (Connect: 0, Receive: 0, Length: 3, Exceptions: 0) Write errors: 0 Total transferred: 46718 bytes HTML transferred: 10437 bytes Requests per second: 677.52 [#/sec] (mean) Time per request: 2.952 [ms] (mean) Time per request: 1.476 [ms] (mean, across all concurrent requests) Transfer rate: 61.82 [Kbytes/sec] received
Connection Times (ms) min mean[+/-sd] median max Connect: 0 0 0.0 0 1 Processing: 0 2 21.1 1 331 Waiting: 0 1 0.8 1 4 Total: 0 3 21.1 1 331
Percentage of the requests served within a certain time (ms) 50% 1 66% 1 75% 1 80% 1 90% 1 95% 4 98% 4 99% 4 100% 331 (longest request) Stix:~ wade$ ab -n 500 -c 10 http://127.0.0.1:4001/yo This is ApacheBench, Version 2.3 <$Revision: 655654 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking 127.0.0.1 (be patient) Completed 100 requests Completed 200 requests Completed 300 requests Completed 400 requests Completed 500 requests Finished 500 requests
Server Software: dumb Server Hostname: 127.0.0.1 Server Port: 4001
Document Path: /yo Document Length: 21 bytes
Concurrency Level: 10 Time taken for tests: 0.710 seconds Complete requests: 500 Failed requests: 27 (Connect: 0, Receive: 0, Length: 27, Exceptions: 0) Write errors: 0 Total transferred: 44462 bytes HTML transferred: 9933 bytes Requests per second: 704.28 [#/sec] (mean) Time per request: 14.199 [ms] (mean) Time per request: 1.420 [ms] (mean, across all concurrent requests) Transfer rate: 61.16 [Kbytes/sec] received
Connection Times (ms) min mean[+/-sd] median max Connect: 0 0 0.2 0 3 Processing: 0 14 58.8 1 331 Waiting: 0 2 2.0 1 10 Total: 0 14 58.8 1 331
Percentage of the requests served within a certain time (ms) 50% 1 66% 1 75% 2 80% 4 90% 7 95% 26 98% 313 99% 330 100% 331 (longest request) Stix:~ wade$
I actually do get some errors.
It looks like there is something inside my seemingly identical CCL/H'toot that makes it run 1/10 as fast as Wade's.
For what it is worth, running 'top' during the benchmark shows that CCL is running at 100%+ CPU, but the 'ab' benchmark tool making the requests is using almost nothing. Unfortunately, profiling on CCL is not straightforward, so I can't figure out where the CPU is spending its time.
It's not terribly important for me, because I'll probably run it on a different platform than a Mac. It's sure irksome and inxplicable.
Thanks to everyone who looked at this.
On Aug 19, 2010, at 3:01 PM, Wade Humeniuk wrote:
I am running a MacBook Pro (about 4 years old). Core 2 ~2.1 GHz
I get no errors in any run.
Seems to run the same no matter what test I do,
CL-USER> (do-dumb-server-loop :port 4001)
Stix:~ wade$ ab -n 500 -c 1 http://127.0.0.1:4001/yo This is ApacheBench, Version 2.3 <$Revision: 655654 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking 127.0.0.1 (be patient) Completed 100 requests Completed 200 requests Completed 300 requests Completed 400 requests Completed 500 requests Finished 500 requests
Server Software: dumb Server Hostname: 127.0.0.1 Server Port: 4001
Document Path: /yo Document Length: 21 bytes
Concurrency Level: 1 Time taken for tests: 0.599 seconds Complete requests: 500 Failed requests: 0 Write errors: 0 Total transferred: 47000 bytes HTML transferred: 10500 bytes Requests per second: 835.27 [#/sec] (mean) Time per request: 1.197 [ms] (mean) Time per request: 1.197 [ms] (mean, across all concurrent requests) Transfer rate: 76.67 [Kbytes/sec] received
Connection Times (ms) min mean[+/-sd] median max Connect: 0 0 0.0 0 1 Processing: 1 1 0.8 1 5 Waiting: 1 1 0.8 1 5 Total: 1 1 0.8 1 5
Percentage of the requests served within a certain time (ms) 50% 1 66% 1 75% 1 80% 1 90% 1 95% 4 98% 4 99% 4 100% 5 (longest request) Stix:~ wade$ ab -n 500 -c 2 http://127.0.0.1:4001/yo This is ApacheBench, Version 2.3 <$Revision: 655654 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking 127.0.0.1 (be patient) Completed 100 requests Completed 200 requests Completed 300 requests Completed 400 requests Completed 500 requests Finished 500 requests
Server Software: dumb Server Hostname: 127.0.0.1 Server Port: 4001
Document Path: /yo Document Length: 21 bytes
Concurrency Level: 2 Time taken for tests: 0.785 seconds Complete requests: 500 Failed requests: 3 (Connect: 0, Receive: 0, Length: 3, Exceptions: 0) Write errors: 0 Total transferred: 46718 bytes HTML transferred: 10437 bytes Requests per second: 637.18 [#/sec] (mean) Time per request: 3.139 [ms] (mean) Time per request: 1.569 [ms] (mean, across all concurrent requests) Transfer rate: 58.14 [Kbytes/sec] received
Connection Times (ms) min mean[+/-sd] median max Connect: 0 0 0.0 0 0 Processing: 0 3 21.5 1 330 Waiting: 0 1 0.8 1 5 Total: 0 3 21.5 1 331
Percentage of the requests served within a certain time (ms) 50% 1 66% 1 75% 1 80% 1 90% 1 95% 4 98% 4 99% 5 100% 331 (longest request) Stix:~ wade$ ab -n 500 -c 10 http://127.0.0.1:4001/yo This is ApacheBench, Version 2.3 <$Revision: 655654 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking 127.0.0.1 (be patient) Completed 100 requests Completed 200 requests Completed 300 requests Completed 400 requests Completed 500 requests Finished 500 requests
Server Software: dumb Server Hostname: 127.0.0.1 Server Port: 4001
Document Path: /yo Document Length: 21 bytes
Concurrency Level: 10 Time taken for tests: 0.679 seconds Complete requests: 500 Failed requests: 22 (Connect: 0, Receive: 0, Length: 22, Exceptions: 0) Write errors: 0 Total transferred: 44932 bytes HTML transferred: 10038 bytes Requests per second: 735.92 [#/sec] (mean) Time per request: 13.588 [ms] (mean) Time per request: 1.359 [ms] (mean, across all concurrent requests) Transfer rate: 64.58 [Kbytes/sec] received
Connection Times (ms) min mean[+/-sd] median max Connect: 0 0 0.1 0 1 Processing: 0 13 59.5 1 337 Waiting: 0 2 1.8 1 10 Total: 0 13 59.5 1 337
Percentage of the requests served within a certain time (ms) 50% 1 66% 1 75% 1 80% 4 90% 6 95% 9 98% 327 99% 330 100% 337 (longest request) Stix:~ wade$
CL-USER> (do-dumb-server-loop/ccl :port 4001)
Stix:~ wade$ ab -n 500 -c 1 http://127.0.0.1:4001/yo This is ApacheBench, Version 2.3 <$Revision: 655654 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking 127.0.0.1 (be patient) Completed 100 requests Completed 200 requests Completed 300 requests Completed 400 requests Completed 500 requests Finished 500 requests
Server Software: dumb Server Hostname: 127.0.0.1 Server Port: 4001
Document Path: /yo Document Length: 21 bytes
Concurrency Level: 1 Time taken for tests: 0.590 seconds Complete requests: 500 Failed requests: 0 Write errors: 0 Total transferred: 47000 bytes HTML transferred: 10500 bytes Requests per second: 847.87 [#/sec] (mean) Time per request: 1.179 [ms] (mean) Time per request: 1.179 [ms] (mean, across all concurrent requests) Transfer rate: 77.83 [Kbytes/sec] received
Connection Times (ms) min mean[+/-sd] median max Connect: 0 0 0.0 0 0 Processing: 1 1 0.8 1 5 Waiting: 1 1 0.8 1 5 Total: 1 1 0.8 1 5
Percentage of the requests served within a certain time (ms) 50% 1 66% 1 75% 1 80% 1 90% 1 95% 4 98% 4 99% 5 100% 5 (longest request) Stix:~ wade$ ab -n 500 -c 2 http://127.0.0.1:4001/yo This is ApacheBench, Version 2.3 <$Revision: 655654 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking 127.0.0.1 (be patient) Completed 100 requests Completed 200 requests Completed 300 requests Completed 400 requests Completed 500 requests Finished 500 requests
Server Software: dumb Server Hostname: 127.0.0.1 Server Port: 4001
Document Path: /yo Document Length: 21 bytes
Concurrency Level: 2 Time taken for tests: 0.738 seconds Complete requests: 500 Failed requests: 3 (Connect: 0, Receive: 0, Length: 3, Exceptions: 0) Write errors: 0 Total transferred: 46718 bytes HTML transferred: 10437 bytes Requests per second: 677.52 [#/sec] (mean) Time per request: 2.952 [ms] (mean) Time per request: 1.476 [ms] (mean, across all concurrent requests) Transfer rate: 61.82 [Kbytes/sec] received
Connection Times (ms) min mean[+/-sd] median max Connect: 0 0 0.0 0 1 Processing: 0 2 21.1 1 331 Waiting: 0 1 0.8 1 4 Total: 0 3 21.1 1 331
Percentage of the requests served within a certain time (ms) 50% 1 66% 1 75% 1 80% 1 90% 1 95% 4 98% 4 99% 4 100% 331 (longest request) Stix:~ wade$ ab -n 500 -c 10 http://127.0.0.1:4001/yo This is ApacheBench, Version 2.3 <$Revision: 655654 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking 127.0.0.1 (be patient) Completed 100 requests Completed 200 requests Completed 300 requests Completed 400 requests Completed 500 requests Finished 500 requests
Server Software: dumb Server Hostname: 127.0.0.1 Server Port: 4001
Document Path: /yo Document Length: 21 bytes
Concurrency Level: 10 Time taken for tests: 0.710 seconds Complete requests: 500 Failed requests: 27 (Connect: 0, Receive: 0, Length: 27, Exceptions: 0) Write errors: 0 Total transferred: 44462 bytes HTML transferred: 9933 bytes Requests per second: 704.28 [#/sec] (mean) Time per request: 14.199 [ms] (mean) Time per request: 1.420 [ms] (mean, across all concurrent requests) Transfer rate: 61.16 [Kbytes/sec] received
Connection Times (ms) min mean[+/-sd] median max Connect: 0 0 0.2 0 3 Processing: 0 14 58.8 1 331 Waiting: 0 2 2.0 1 10 Total: 0 14 58.8 1 331
Percentage of the requests served within a certain time (ms) 50% 1 66% 1 75% 2 80% 4 90% 7 95% 26 98% 313 99% 330 100% 331 (longest request) Stix:~ wade$
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
Just a note. I am not using the bknr repository. Just straight up asdf-install
Here is a directory listing of all the asdf packages,
Stix:site wade$ pwd /Users/wade/.asdf-install-dir/site Stix:site wade$ ls -l total 0 drwxr-xr-x 41 wade wade 1394 5 Jun 14:23 alexandria drwxr-xr-x 12 wade wade 408 5 Jun 14:24 anaphora-0.9.3 drwxr-xr-x 13 wade wade 442 28 Jul 2008 babel_0.3.0 drwxr-xr-x 10 wade wade 340 24 Dec 2009 bordeaux-threads-0.7.0 drwxr-xr-x 19 wade wade 646 16 Jun 2009 cffi_0.10.5 drwxr-xr-x 23 wade wade 782 5 Jun 14:23 chunga-1.1.0 drwxr-xr-x 27 wade wade 918 5 Jun 14:23 cl+ssl-2008-11-04 drwxr-xr-x 11 wade wade 374 5 Jun 14:23 cl-base64-3.3.3 drwxr-xr-x 16 wade wade 544 5 Jun 14:23 cl-fad-0.6.3 drwxr-xr-x 11 wade wade 374 5 Jun 14:23 cl-interpol-0.2.1 drwxr-xr-x 52 wade wade 1768 5 Jun 14:26 cl-pdf drwxr-xr-x 42 wade wade 1428 5 Jun 14:23 cl-ppcre-2.0.3 drwxr-xr-x 8 wade wade 272 29 Mar 2007 cl-prevalence drwxr-xr-x 48 wade wade 1632 5 Jun 14:26 cl-typesetting drwxr-xr-x 19 wade wade 646 5 Jun 14:23 cl-unicode-0.1.1 drwxr-xr-x 23 wade wade 782 5 Jun 14:24 cl-vectors-0.1.3 drwxr-xr-x 11 wade wade 374 5 Jun 14:23 cl-who-0.11.1 drwxr-xr-x 20 wade wade 680 5 Jun 14:23 closer-mop_0.61 drwxr-xr-x 44 wade wade 1496 20 Apr 12:37 clsql-5.1.0 drwxr-xr-x 19 wade wade 646 5 Jun 14:23 drakma-1.1.0 drwxr-xr-x 18 wade wade 612 22 May 13:18 elephant drwxr-xr-x 45 wade wade 1530 5 Jun 14:23 flexi-streams-1.0.7 drwxr-xr-x 46 wade wade 1564 5 Jun 14:23 hunchentoot-1.1.0 drwxr-xr-x 10 wade wade 340 29 Apr 21:24 ironclad_0.28 drwx------ 5 wade wade 170 5 Jun 14:23 md5-1.8.5 drwxr-xr-x 11 wade wade 374 26 Feb 22:25 parenscript-2.1 drwxr-xr-x 9 wade wade 306 5 Jun 14:23 puri-1.5.4 drwxr-xr-x 8 wade wade 272 5 Jun 14:23 rfc2388 drwxr-xr-x 7 wade wade 238 5 Jun 14:25 rt-20040621 drwxr-xr-x@ 41 wade wade 1394 5 Jun 14:23 rucksack drwxr-xr-x 8 wade wade 272 26 Jun 2008 s-sysdeps drwxr-xr-x 8 wade wade 272 18 Jan 2006 s-xml drwxr-xr-x 40 wade wade 1360 5 Jun 14:24 salza2-2.0.7 drwxr-xr-x 6 wade wade 204 5 Jun 14:23 split-sequence drwxr-xr-x 10 wade wade 340 16 May 2009 trivial-backtrace drwxr-xr-x 10 wade wade 340 19 Oct 2009 trivial-features_0.6 drwxr-xr-x 11 wade wade 374 5 Jun 14:23 trivial-gray-streams-2008-11-02 drwxr-xr-x 7 wade wade 238 5 Jun 14:23 trivial-utf-8 drwxr-xr-x 18 wade wade 612 20 Apr 12:32 uffi-2.0.0 drwxr-xr-x 3 wade wade 102 21 Jan 2006 unit-test drwxr-xr-x 18 wade wade 612 5 Jun 14:23 usocket-0.4.1 drwxr-xr-x 34 wade wade 1156 5 Jun 14:24 vecto-1.4.3 drwxr-xr-x 12 wade wade 408 5 Jun 14:26 yason-0.1 drwxr-xr-x 40 wade wade 1360 5 Jun 14:24 zpb-ttf-1.0 drwxr-xr-x 16 wade wade 544 5 Jun 14:24 zpng-1.2 Stix:site wade$
It's not a problem in the bknr repository. Just tried it and everything works. Update ccl?
wade
-
Andrey Moskvitin -
Hans Hübner -
JTK -
lukas.georgieff＠hotmail.com -
Robert Synnott -
Wade Humeniuk