TVS Benchmark 2

Benchmarks

concurrency with 4KByte file

To get the following results I used "ab -n 10000 -c [various, see table] 127.0.0.1/t4k.html". The t4k.html has a size of 4096 bytes. I testet thttpd 2.25b, lighttpd 1.3.2, dpfTVS 2.0.915 and hssTVS 0.138 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. As OS I used SuSE 9.1 and the computer was rebooted between the different server sessions.

The raw results:

-c values	1	5	10	50	100	150	200	250	300	350	400	450	500
thttpd	2398	2346	2208	1916	1679	1451	1059	805	609	512	434	363	311
lighttpd	2448	2439	2293	2015	1751	1288	972	754	640	552	489	411	374
dpfTVS	2383	2054	1940	1911	1866	1824	1821	1782	1725	1703	1714	1637	1655
hssTVS	2444	2413	2220	2160	2192	2163	2154	2154	2096	2088	2071	2027	2060

A few thoughts to the results
The initial tests with only 1 connection show that the servers are not so far appart in their speed. But the higher the concurrency gets the higher the difference between my servers and the others. While mine remain on a rather flat line the both others decline. Why is that? The performance drop of both TVS servers in the beginning do show that they also suffer when the concurrency goes up, the dpfTVS even more so, showing clearly the drawback of one task per connection. It seems that my servers follow a more sophisticated internal path. So it does pay off to know about the low level stuff after all. When I think back to the beginning of my work on the TVS internals I do remember equal behaviour. I was so upset about it that I did spend quite some time trying to work around what I deemed to be broken. I tweaked the internal timing up to the point that I do for example force the tasks of dpfTVS to give up their work time in situations that would cause a block a bit later anyway. These tweakings are the reason the server won't work in anything below SCHED_RR on a 2.6 kernel with the new scheduler (it works fine with SCHED_OTHER together with LinuxThreads though). While hssTVS of course has but one task, it does in fact the same in it's own way as I copied the successful approach for it.

BACK