"Example isn't another way to teach, it is the only way to teach."
(Albert Einstein)

The (special) case of Microsoft IIS

G-WAN v1.0.6 is much faster than G-WAN v1.0.1 tested below.

After it left the user-mode Winsock API (WS2_32.DLL) to run in a kernel driver called the 'Windows HTTP Stack' (HTTP.SYS), IIS 6.0 got an instant 3x boost.

But the Microsoft Platform SDK makes it clear that there is a price to pay:

"User-mode vs. Kernel-mode Drivers"
"In Windows NT 4.0, drivers were moved into kernel mode to improve performance. However, when a kernel-mode driver fails, it can crash an entire system, whereas the failure of a user-mode driver causes only the current process to crash. Windows Server 2003 can still run kernel-mode drivers, although this is not recommended for the stability reasons mentioned previously." (Microsoft TechNet, March 2003)

Trying to avoid this, WinServer 2008 reboots when it detects kernel-patching

Just curious, I benchmarked* IIS 7 and the G-WAN 1.0 portable code:
ab -k -c 120 -t 1 http://10.10.2.6/1000.html

Despite the (growing exponentially with concurrency) user-mode overhead G-WAN 1.0 manages to outdo IIS 7's kernel-mode performances!

Encouraged by this success, TrustLeap also benchmarked G-WAN's C servlets.
This time, as ASP.Net is user-mode, IIS+ASP.Net share half G-WAN's handicap.

ab -k -c 40 -t 1
IIS: http://10.10.2.6/hello.aspx     G-WAN: http://10.10.2.6/csp?hello

Microsoft prefers to run in the kernel, but TrustLeap shines in user-mode:

IIS ASP.Net is 5x slower than G-WAN servlets (that beat IIS' static pages).

And G-WAN (100 KB with C servlets included) is thousands times smaller than Microsoft IIS 7 (501 MB will all modules -the bare server core takes 228 MB).

Note: after ASP.Net is enabled on Windows Vista/2008, the TCP/IP stack is 10% slower, penalizing all other applications (G-WAN included). This is due to the way Microsoft interfaced ASP.Net to the HTTP.SYS kernel driver.

Want to see how G-WAN does on Solaris, Mac OS X or BSD? Help us do it!

(*) ab and servers were run on the same host, rebooted for each tests serie; tunable options: no log files, accept_max=1024, connection_timeout=5, keepalive_max=100000.