Hacker News new | past | comments | ask | show | jobs | submit login

He come across as a fruit basket if you ask me; Conspiracy theories aside, when he dissed libevent and libev[1] on his own forum [2], the author of libev took time to reply and it became pretty apparent that this guy does not know a whole of lot of what he is talking about. He has also taken several stabs at Igor and Nginx and when Igor politely pointed out that g-wan actually use more syscalls than nginx for the same request - meaning that g-wan user-land code basically does nothing since it apparently is faster than nginx, he went on a crazy rampant trying to explain away the fact.

[1] Libev is the event engine used by node.js.

[2] http://forum.gwan.com/index.php?p=/discussion/151/libevent-a...




I have no expertise in these areas, but let me point out that you didn't give an example of where you got the idea that the gwan author was not knowledgeable enough. If this was so apparent to you, then it should be easy to enumerate your concerns. In addition the gwan author continues to release detailed benchmarks against all competitors, in which Gwan always leads. Nginx and others do not do that. I don't know what your criticism is supposed to accomplish, but I hardly think the number of syscalls matters when Gwan is still faster. I'm not defending the guy and certainly not his attitude but I just don't agree with how you laid out your criticism.


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: