Take the 2-minute tour ×

Lighttpd, nginx and others use a range of techniques to provide maximum application performance such as AIO, sendfile, MMIO, caching and epoll and lock free data structures.

My collegue and I have written a little application server which uses many of these techniques and can also server static files. So we tested it with apache bench and compared ours with lighttpd and nginx and have at least matched the performance for static content for files from 100 bytes to 1K.

However, when we compare the transaction rate over the same static files to that of G-WAN, G-WAN is miles ahead.

I know this question may be a little subjective but what techniques apart from the obvious ones I've mentioned might Pierre Gauthier be using in GWAN that would enable him to achieve such astounding performance?

share|improve this question

2 Answers 2

Following G-WAN server for years, I have read the (many) talks covering this question on the old G-WAN forum.

From what I can remember, what was repeatedly addressed were the program:

  1. architecture (specific comparisons were made with nginx, lighty and cherokee)
  2. implementation (how overall branching, request parsing and response building were made)
  3. lean common path (the path followed by all types of requests: dynamic, static, handlers)

Pierre often mentionned other servers to explain what in their specific architecture and implementation was slowing them down.

As time goes, since G-WAN seems to stack more and more features (C# scripts support, a reverse-proxy and a load balancer are expected with the next version), it seems that those 3 points above are more and more important.

This is probably why each new release of G-WAN seems to be willing to be faster than the previous: the more work you do, the more extra fat must be eliminated because its cost gets higher. And like for a race car or a plane this is an incremental process, one calling for more of the other.

If you are looking for the 'secret' of G-WAN's speed then I guess that here is the key point. But if you want more details then you should rather talk directly to the G-WAN author.

share|improve this answer
Design is the most obvious. However, subsequent testing shows my CPU load at around 30%. The bottleneck seems to be the network card or kernel. GWAN is still outperforming what we have. Is there some special initialization tricks involved in upping the packets/s through the network card? –  Matt Sep 24 '12 at 1:32
If the bottleneck was the kernel then G-WAN could not be faster than others. G-WAN's CPU load is lower because its user-mode code is (much) faster. The hello.c servlet does not touch the disk so the kernel is not involved to load a file - and here also G-WAN is faster than an nginx module (which, unlike G-WAN servlets, is NOT loaded dynamically so it should have an advantage). Faster, leaner code and better program architecture. That's all what G-WAN is about. –  Gil Oct 30 '12 at 13:51

Check out G-WAN's timeline. An update on August 8, 2011 might give you idea on what he is using.

G-WAN Timeline

Pierre mentioned that G-WAN uses it's wait-free Key-Value store a lot on G-WAN's core functions. Which gives it more speed since there's no locks being used.

He also uses a Lorenz Waterwheel inspired technique to handle threads. I am not sure how it works but he said that it allows G-WAN to run faster in every possible case.

share|improve this answer
Right, the KV store is used for lists like the virtual hosts and the many-language servlets while the Lorenz Waterwheel is how the architecture is organized to deal with worker threads. The point is that Waterwheel is dynamically adjusted with the load in order to offer the best possible responsivity despite changing load conditions. –  Gil Oct 30 '12 at 13:58
Except that serving up static pages doesn't need to touch the key/value store. Unless he's using it as a cache Besides, I doubt that it's faster than mdb. Actually, if you look up what a Lorenz Waterwheel is, it essentially means random. My guess is he's making up some jargon that sounds good but isn't what it's actually doing. –  Matt Dec 11 '12 at 0:13
Can you prove that mdb is faster than G-WAN KV store? Lorenz Waterwheel is not just random. One other concept is sensitivity to initial condition. This can be applied to cores as initial condition. The algorithm will work completely differently when using 1,2,4... cores. My guess is we just don't know how he really does it that's why it looks meaningless. –  Richard Heath Dec 11 '12 at 15:46
Good points Richard. –  Matt Dec 13 '12 at 23:39

Your Answer


