The number of syscalls most definitely matters. Syscalls define what the application actually does on the system. Whenever an application opens a file, write or read it is a syscall. Syscalls are expensive and if you want to write a fast server you want to minimize these calls as much as possible. http://en.wikipedia.org/wiki/Syscall

The author of gwan sits behind his closed source application and use benchmarks "authoritatively" to criticize open source competitors. This is very bad form as there is no way for these authors to investigate and criticize the gwan code in return.

However, one can use trace to investigate the number of syscalls gwan uses for a known operation (e.g. serving a small static file). If gwan was the fastest server out there one would of course expect that it uses the fewest and absolute minimum number of syscalls of all servers. When it turns out that it doesn't, the author of gwan has a explanation problem.

Add to the above premise that gwan does not implement HTTP/1.1 and hardly does HTTP/1.0.

Before we conclude, lets look at what a web-server or application server does. The following abstract loop basically define such a server:

   while true
         read request
         <process>
         write response
   end

If you skip or minimize the <process> part, any newbie programmer can write a server that can handle a large amount of requests per second. And this is exactly what gwan does, while the other servers implements the full HTTP/1.1 state machine. It is in the <process> part that the work of a server, skills and excellence can be found.

Gwan is a classic example of "The Emperor Wears No Clothes" and the so-called benchmarks are a joke as it compares a naked gwan with a magnificent clothed emperor such as nginx.