I did some tests with httperf:
*First test with file-to-string function:*
Total: connections 100 requests 100 replies 89 test-duration 67.869 s
Connection rate: 1.5 conn/s (678.7 ms/conn, <=1 concurrent connections) Connection time [ms]: min 492.0 avg 638.7 max 1151.0 median 572.5 stddev 150.4 Connection time [ms]: connect 1.3 Connection length [replies/conn]: 1.000
Request rate: 1.5 req/s (678.7 ms/req) Request size [B]: 93.0
Reply rate [replies/s]: min 1.0 avg 1.3 max 1.8 stddev 0.2 (13 samples) Reply time [ms]: response 511.0 transfer 126.4 Reply size [B]: header 368.0 content 21324.0 footer 0.0 (total 21692.0) Reply status: 1xx=0 2xx=89 3xx=0 4xx=0 5xx=0
CPU time [s]: user 28.77 system 38.89 (user 42.4% system 57.3% total 99.7%) Net I/O: 27.9 KB/s (0.2*10^6 bps)
Errors: total 11 client-timo 11 socket-timo 0 connrefused 0 connreset 0 Errors: fd-unavail 0 addrunavail 0 ftab-full 0 other 0
*Second test with handle-static-file:*
Total: connections 100 requests 100 replies 16 test-duration 93.867 s
Connection rate: 1.1 conn/s (938.7 ms/conn, <=1 concurrent connections) Connection time [ms]: min 594.0 avg 807.4 max 1393.0 median 690.5 stddev 240.2 Connection time [ms]: connect 0.6 Connection length [replies/conn]: 1.000
Request rate: 1.1 req/s (938.7 ms/req) Request size [B]: 93.0
Reply rate [replies/s]: min 0.0 avg 0.2 max 1.0 stddev 0.3 (18 samples) Reply time [ms]: response 637.1 transfer 166.0 Reply size [B]: header 348.0 content 21324.0 footer 0.0 (total 21672.0) Reply status: 1xx=0 2xx=16 3xx=0 4xx=0 5xx=0
CPU time [s]: user 40.12 system 53.39 (user 42.7% system 56.9% total 99.6%) Net I/O: 3.7 KB/s (0.0*10^6 bps)
Errors: total 84 client-timo 79 socket-timo 0 connrefused 0 connreset 5 Errors: fd-unavail 0 addrunavail 0 ftab-full 0 other 0
As can be seen from the second test there were lots of time-out requests. Also as I was watching the CPU usage (with top) during first test CPU load was ~2%, during second test the CPU load was ~90% with memory constantly growing and shrinking (probably GC was causing this load). Also during some of handle-static-file tests I ran into heap allocation problems so I had to unload the lisp image and restart it. Well, it could be just my particular system's problem.
Andrew
On Fri, Jun 20, 2008 at 2:20 PM, Edi Weitz edi@agharta.de wrote:
On Fri, 20 Jun 2008 12:56:33 -0400, "Andrei Stebakov" lispercat@gmail.com wrote:
I had to come up with some way to cache dynamic files that I have to serve, so I ended up with a bunch of static files which I served by a simple function: (defun file-to-string (path) "Reads a file into a string" (if (probe-file path) (with-open-file (in path) (let ((str (make-string (file-length in)))) (read-sequence str in) str))))
The performance was very good, but then I thought that it's not the proper way to serve static files as there is a hunchentoot function handle-static-file. When I started using the hunchentoot's function the response time almost tripled and when I run "top" program to monitor CPU usage it jumps up to 60% (on my PIII 600 MHz) CPU, whereas using file-to-string CPU usage stays with 2% (maybe because the serving time is much shorter top doesn't catch that CPU peak).
How did you measure the response time? Which version of FLEXI-STREAMS are you using? Did you try with the development version?
My question is what could be the reason I see this behaviour? (I am using SBCL 1.0.15 with latest dependences of hunchentoot-0.15.7)
Look at the source code of handle-static-file. It uses a fixed size buffer which is likely smaller than your file. _______________________________________________ tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel