-- Testsoftware was Zeusbench 1.01 -- client SuSE 9.1, runlevel 5 with KDE without any running tasks AMD 1400 512MByte DDR266 cheap 10/100 MBit LAN-Card based on Realtek RT8139 server SuSE 9.2, runlevel 3 without any additional tasks AMD K6/450 (no 2nd level cache) 384 Mbyte SDRAM 100MHz cheap 10/100 MBit LAN-Card based on Realtek RT8139 Connected via a cheap switching 5 Port-Router, Longshine LCS-883R-SW500M+, both running at 100MBs Client and Server were rebooted between the usage of the different servers. The retrieved file was a 1010 Byte gif. The exact command was "zb 192.168.0.3 /aeh.gif -p 80 -n 10000" with changing -c, once with and once without -k for persistent connection I testet - lighttpd 1.3.6, fresh compiled with epoll and "server.max-keep-alive-requests=128" - thttpd 2.25b, fresh compiled (with poll?), disabled log-file support - boa 0.94.13 fresh compiled with default settings. any kind of log files were disabled - dpfTVS 2.0.923 beta, fresh compiled, dynamic pre-fork (go figure) - dpfTVS*, the same, but uses the built in primitive cache to pre-map/load user specified directories - litespeed 2.0 standard, logfiles disabled, without .htaccess or any other security enabled, expires disabled, using poll - hssTVS 0.176 alpha, fresh compiled with epoll - dptTVS 2.0.923 beta, based on dpfTVS but uses threads together with the dynamic filecache of hssTVS Results: the first value is always without, the second value with -k -c value lighttpd thttpd boa dpfTVS (dpfTVS*) litespeed std hssTVS dptTVS 1 904/1253 816/ 806 879/1268 842/1264 ( 999/1599) 881/1329 1204/1975 998/1528 2 1080/1653 941/1004 1145/1767 932/1569 (1125/2241) 999/1656 1706/3689 1141/2213 3 1048/1662 1011/1046 1125/2219 926/1554 (1131/2181) 1015/1732 1718/3957 1142/2200 4 1057/1668 1049/1075 1179/2240 911/1539 (1144/2129) 1025/1757 1712/4037 1153/2155 5 1047/1663 1126/1127 1207/2241 924/1541 (1133/2095) 1026/1751 1698/4015 1165/2127 6 1059/1671 1111/1149 1208/2236 933/1521 (1128/2131) 1032/1771 1718/4026 1159/2091 7 1060/1678 1153/1129 1221/2257 924/1524 (1109/2104) 1040/1756 1701/3950 1149/2093 8 1057/1660 1096/1176 1243/2253 914/1530 (1114/2080) 1034/1764 1682/3961 1132/2078 9 1060/1671 1152/1153 1253/2282 919/1517 (1107/2103) 1033/1768 1673/3948 1151/2096 10 1051/1634 1112/1203 1230/2271 928/1514 (1118/2089) 1062/1800 1669/3805 1144/2085 15 1047/1667 1173/1211 1231/2321 917/1513 (1111/2077) 1065/1758 1672/3893 1147/2068 20 1051/1669 1184/1207 1270/2338 910/1503 (1080/2025) 1057/1795 1670/3881 1142/2053 25 1033/1659 1183/1206 1263/2329 899/1487 (1089/2010) 1056/1791 1670/3873 1124/2035 30 1035/1655 1183/1206 1254/2345 896/1480 (1096/2028) 1046/1809 1689/3887 1117/2001 35 1029/1624 1167/1197 1275/2346 897/1480 (1092/1970) 1045/1813 1678/3870 1096/1989 40 1011/1623 1163/1198 1288/2368 892/1472 (1093/1977) 1041/1802 1639/3876 1115/1992 45 1020/1586 1175/1199 1263/2334 894/1429 (1089/1977) 1030/1802 1649/3851 1110/1985 50 1003/1554 1157/1212 1323/2353 888/1424 (1086/1979) 1025/1804 1642/3842 1100/1979 60 997/1548 1162/1196 1304/2356 894/1422 (1084/1925) 1037/1794 1614/3857 1107/1969 70 999/1537 1144/1193 1306/2338 882/1418 (1085/1913) 1030/1803 1611/3848 1103/1963 80 990/1544 1148/1199 1319/2332 890/1408 (1084/1898) 1019/1723 1630/3796 1106/1969 90 972/1529 1168/1191 1249/2177 870/1377 (1068/1885) 1015/1726 1645/3788 1089/1960 100 998/1551 1154/1183 1281/2179 877/1376 (1079/1872) 1004/1724 1640/3719 1083/1948 110 994/1524 1155/1175 1268/2167 880/1359 (1065/1858) 1010/1709 1630/3648 1076/1942 120 997/1550 1149/1171 1257/2184 877/1354 (1069/1844) 1006/1711 1606/3613 1077/1935 130 974/1552 1131/1167 1271/2174 874/1341 (1069/1831) 1014/1703 1578/3608 1063/1931 140 966/1539 1130/1164 1289/2178 873/1338 (1065/1823) 1014/1716 1583/3532 1068/1906 150 982/1542 1143/1172 1262/2165 870/1326 (1072/1806) 1018/1726 1582/3515 1085/1916 160 986/1527 1139/1163 1262/2181 861/1321 (1061/1800) 1015/1711 1580/3514 1066/1894 170 979/1545 1145/1174 1267/2173 861/1315 (1081/1796) 1013/1714 1563/3499 1069/1910 180 995/1532 1144/1166 1270/2185 861/1310 (1069/1796) 1017/1717 1580/3490 1061/1900 190 960/1538 1154/1175 1267/2168 856/1308 (1061/1798) 1005/1712 1577/3470 1051/1906 200 988/1520 1141/1169 1266/2165 859/1305 (1074/1795) 1023/1699 1572/3483 1047/1898 210 985/1540 1155/1182 1283/2165 859/1314 (1077/1796) 1024/1702 1591/3469 1071/1888 220 975/1536 1143/1169 1279/2192 853/1316 (1069/1788) 1026/1703 1603/3484 1070/1876 230 974/1525 1147/1180 1286/2179 859/1316 (1067/1788) 1025/1702 1599/3477 1068/1872 240 978/1528 1134/1165 1290/2180 862/1316 (1058/1790) 1014/1703 1607/3463 1066/1870 250 983/1526 1144/1183 1272/2185 864/1309 (1068/1786) 1013/1269 1609/3458 1068/1864 As far as I know (the free) lighttpd doesn't use a full filecache but caches the file status data. You can however register the full version which has a cache module. Well, I won't spend my money for that just to run some tests... I decided to use epoll as it is re- commended on Linux systems for better overall performance. It is written in C. thttpd uses a dynamic filecache since version 2.21 or so and I didn't make the effort to look up just how to get it running with epoll (compiler switch?). There is no support for persistent connections. However, I found a (non-free) premium version in the net that claims to be 30% faster than the normal one that also supports persistent connections. Both are written in C. Boa has me somewhat baffled. Well, it is written in C and uses good old select. From what I've seen, it uses a dynamic filecache. It does support keep-alive connections for http/1.0, but in my tests with httperf it lacked persistent http/1.1 ones. I didn't bother to ckeck if http/1.1 is supported at all though. Just to mention it, I had quite some trouble to compile that thing on my PC and it didn't go without making changes to the code. Nothing serious, just some macros wouldn't get parsed right. So SuSE isn't the best host for it. It didn't come unexpected that my dpfTVS is the slowest in the field. Actually I am kinda surprised that it did show such a good performance after all and it did keep up well with lighttpd and litespeed. The decline we can see is due to context switch times, no way to avoid that, but I think I did a good job keeping the number of concurrent tasks low, of course I can't do that with the persistent requests, so we see the full impact of the increased task number. Considering that the architecture doesn't allow for a dynamic filecache the numbers are quite high and when using one of the built in static cache types, it is a different matter alltogether. I admit that the cache is not really a normal mode of operation, but it is certainly an existing feature, so I don't feel too bad to bring it up. Look at it, a forking core that's capable to hold itself against multi- plexing "4th" generation servers. I bet we'll see even better numbers on HT enabled CPUs, let alone the fact that dpfTVS will fully benefit from multiple CPU(-core) setups. dpfTVS is written in C++. I was pretty excited when I got LiteSpeed. After all they should be pretty fast. I tested the free standard version, the full comercial is a lot faster. The standard almost made it to last place, long way from the faster servers it is almost on par with dpfTVS. They should really consider to give it a slight boost to bring it to comparable speeds with at least thttpd. I made some calculations based on the benchmark on their page and it seems this professional version is a bit faster than hssTVS without keep-alive and significantly slower with keep-alive enabled. Hard to tell if that's really right though, beside that their results are based on the 1.1 version, not the 1.5.11, my system has a lousy ram speed and the celeron has additionally a better cache miss behaviour, both factors have a strong influence on apps like caching www-servers. It seems the free litespeed doesn't use any kind of caching at all. It's written in C++, but I've no clue what base technique they use. Update to 2.0... The 2.0 Version uses poll and is overall 11% faster for non-keep-alive requests and around 22% faster when keep alive is enabled. I am somewhat baffled though about the very low number shown at 250 concurrent keep-alive connections. The status of ZB shows that the number of kept-alive requests is by far too low (5056 from 10000), especially as the max concurrent value was set to 300(default setting). Here it was even slower than 1.5. Well, while it is considerable faster than the old version 1.5 I tested before, it still fails to overcome Boa or even my dptTVS. Actually, comparing my numbers with the results they show on their page, my hssTVS is able to beat the professional LiteSpeed and comes even near Tux 2.2, so I have every right to go party tonight. The 2.0 Version is also considerable faster when it comes to bigger files. So, in case you stll use 1.5 you really should upgrade to this newer version. hssTVS 0.163 is about as fast as I think I can get it without starting to tune it with assembler. I checked the speed without cache for fun, it was at least as fast as Boa (example -c 4 1200/2443). It seems that I've hit a barrier again, perhaps even the last one, where any further changes will bring next to nothing. It is true though, that 163 is faster on a newer Athlon processor than 159 was, so I guess I just lack the right hardware. I also assume that I'll loose a bit speed again when I bring in new features. I never thought about using anything else but epoll, it suits my needs too well. Btw, hssTVS is written in C++. dptTVS 2.0.923 is a dead end, I made it especially for these benchmarks (took me 3 hours), so don't look for it. It is true that it was a lot faster than dpfTVS as long as both ran in "normal" mode, but dptTVS looses a lot speed with cgi. Besides, one server type using threads/tasks is really enough. I've been asked why I bother to keep either around as hssTVS is so fast. Well, the programming with a normal mode server is a lot easier (aka straight forward) than the event driven models, so I test new features in the easier models and then port them once they are good enough. Plus, I need those classes for web application development. Well what to say, dptTVS stops short of Boa and leaves all others behind. It made its point. I tried to include Cherokee too as it claims to be faster than Boa, but I couldn't get it to compile at all, so I'll have to skip that one. I try to get a hold of some others to add them to this file. Some words about benchmarking in general. To test the performance of the server it is essential that the client is a lot faster, else you test the speed of the client which is not what you want to do. If the resulting transfer speeds come anywhere near the max bandwidth of the lan, then the results are also useless, as this bottleneck would level the results out. At it's highest hssTVS reached over 4.5MBytes/sec what is still well within the 100MBit limit. However, with a 4KByte file it's barely sufficient and any file larger than that is definitely beyond my hardware. I'll make new benchmarks once I can afford to upgrade to a full 1GBit network. Some numbers on that: retrived was an 100KByte (exact size) file: -c 100 dptTVS: 109.15 rps (11705.69 kb/s) dpfTVS: 108.19 rps (11648.98 kb/s) hssTVS: 107.76 rps (11623.58 kb/s) litespeed 2.0: 105.85 rps (11492.98 kb/s) thttpd: 101.19 rps (11133.75 kb/s) lighttpd: 91.81 rps ( 9922.26 kb/s) boa: 86.36 rps ( 9261.93 kb/s) litespeed 1.5: 84.81 rps ( 9113.41 kb/s) You might think that this shows that the theoretical max of 12.5 or so MB/sec is still not reached. But actually we don't see all of the cake here. What isn't shown is the tcp, the ip or even the http overhead, let alone the ethernet specific problems that kick in when we reach around 40 or so % of the theoretical max. Add those and you see that the line has limited the speed of the contestants. Perhaps I could/should re-activate my old P200 system? So, what about the 4K file... Take a look, my hardware would be enough to test all but hssTVS: retrieved was a 4KByte File -c 10 -k hssTVS: 2223.21 rps (9577.59 kb/s) dptTVS: 1483.02 rps (6409.61 kb/s) boa: 1413.03 rps (6108.97 kb/s) litespeed 2.0: 1322.40 rps (5737.89 kb/s) dpfTVS: 1113.71 rps (4813.45 kb/s) lighttpd: 1084.48 rps (4723.96 kb/s) litespeed 1.5: 1043,84 rps (4529.23 kb/s) thttpd: 898.39 rps (3897.22 kb/s) As you can see, my hssTVS allready maxes the line nearly out. Under these conditions it's hard to say if it couldn't be faster with more available bandwidth.