TVS Benchmark 1

Benchmarks

concurrency with 1KByte file

To get the following results I used "ab -n 10000 -c [various, see table] 127.0.0.1/pics/aeh.gif". The aeh.gif has a size of 1010 bytes and should normally fit together with its http header in one packet. I testet thttpd 2.25b, lighttpd 1.3.2, dpfTVS 2.0.914 and hssTVS 0.136 against each other. For thttpd I disabled the log file. Neither dpfTVS nor hssTVS used their static or half-static caches. dpfTVS ran in SCHED_RR with a priority setting of 1 (which is the lowest I can set for it) while all others used SCHED_OTHER (normal) with a nice of 0. The test computer was an AMD Athlon 1400 with 512MByte DDR266 ram, the OS was SuSE 9.1 and the computer was rebooted between the different server sessions.

The raw results:

-c values	1	3	5	10	50	100	200	300	400	500
thttpd	2445	2447	2458	2367	2111	1852	1210	702	482	359
lighttpd	2534	2456	2481	2336	2042	1844	1032	699	503	387
dpfTVS	2412	2270	2121	2080	2004	1957	1989	1799	1783	1734
hssTVS	2586	2579	2536	2483	2432	2412	2322	2271	2250	2229

A few thoughts to the results
I think the results speak very clearly for themselves. While both, thttpd and lighttpd, show a major performance breakdown when the load increases, neither hssTVS nor dpfTVS have such problems. Actually my servers keep on running true to the line even when the load is increased to 1000, here neither thttpd nor lighttpd respond at all and ab times out.
People might say my standard values of 1010 workers for both servers have something to do with it and it would have been true for the here tested versions. But as of hssTVS 0.138 and dpfTVS 2.0.915 the performance keeps on roughly the same level even if the workers are limited to 100.
I've also made some tests using the static/half-static feature of my servers. dpfTVS starts then at 2613/2556 and hssTVS at 2803/2718. However, the percentual speed advantage gets smaller the higher the load gets.

BACK