G-WAN vs Nginx

G-WAN		Nginx
	VS
http://gwan.ch		http://wiki.nginx.org

Both G-WAN (freeware) and Nginx (open-source) are HTTP servers for Linux and Windows. Both intend to be "light" and "fast". So Nginx vs G-WAN was an obvious fit.

In Nov. 2010, nginx is 8 years old while G-WAN is not yet 2 years old.

Using a radically different design, TrustLeap G-WAN publish open-sourced benchmarks that show it is much faster than all others.

Other servers do no publish comparative benchmarks because they do not make a significant difference with others.

This article

Unlike the other Web servers, G-WAN is systematically censored from Wikipedia and this page, like http://forum.gwan.com, is often vandalised by the anonymous fans of other Web servers who censor all independently published benchmarks.

Showing how legit are their positions, they cannot restrain themselves from posting insults on the discussion page of this article as well as on the G-WAN forum.

Architecture

Both G-WAN and nginx are asynchronous servers.

'Asynchronous' means that concurrency (serving several clients concurrently) is handled by a few threads handling many connections via events. This approach differs from the method used by Apache which uses a thread for each client request.

As each thread consumes memory resources to maintain its state (local variables) and requires CPU resources when the system emulates a multi-task environment by switching from one thread to another, the asynchronous method is more efficient because it is much lighter.

G-WAN runs as a single process with a thread per physical CPU (or Core).

Nginx runs as a master process and several worker processes.

But only G-WAN scales on multi-Core CPUs, outperforming Nginx by a factor 4 on a 6-Core CPU... while using 3 times less memory.

Design

G-WAN aims at being super-fast without congfiguration, while offering innovative features (C, C++, Objective-C/C++, scripts, Key-Value store, email client, GIF I/O, 2D drawing, charts and sparklines, crypto, RNGs...) that may look a bit too developer-oriented for Web designers but which will please programmers.

nginx has many traditional Web server features which have appealed a large number of loyal users in a decade-like lifespan. They may be difficult to grasp because of a complex design and many configuration options.

Configuration Files

Like all other Web servers, nginx uses configuration files that may look cryptic to newcomers. The rationale is that configuration files are needed to let users extract the best possible performances by tweaking server options.

G-WAN does not use configuration files. Instead, users define Web sites, Virtual Hosts and Aliases by just creating folders under the G-WAN root directory. As those folders must exist to store contents, G-WAN considers that configuration files are redundant (and a potential source of errors).

G-WAN has legitimated its position (about configuration files) by achieving better performances than all the other Web servers - without the need to tune any option.

C/C++/Objective-C G-WAN scripts vs. Nginx Perl scripts

G-WAN natively supports Assembly, ANSI C, C++ and Objective-C/C++ (which outperform ASP.Net C#, Java and PHP by several orders of magnitude in speed and scalability) and Javascript, Lua, Google Go and Python are supported by G-WAN handlers which call a library that implements the language. PHP will be added when a thread-safe PHP-embed library or compiler is made publicly available.

nginx supports native Perl scripts, but Perl cannot decently compete with C/C++/Objective-C scripts so nginx must delegate dynamic content generation to other backend servers or scripting engines (like PHP) via interfaces (like fastCGI or SCGI) which must be installed and configured separately and which overhead is significantly consuming memory and CPU resources.

A problem, with PHP (80 MB), Java (120 MB) or C# (200+ MB), is the footprint of the runtime which is constantly trashing CPU caches by competing with the code of the Web server.

By comparison, G-WAN's C/C++/Objective-C scripts are part of the G-WAN server (a single executable file which footprint is about 100 KB).

Libraries

Any existing system or third-party library can be used directly by G-WAN C/C++/Objective-C scripts - thanks to the G-WAN "pragma #link" directive which links static or shared library (like CURL, SQLite, the PostgreSQL or mySQL client libraries, and any existing image processing or encryption tool) without any interface or modification.

Like for the memcached library, nginx requires a complex dedicated module to create an interface with a library. This is making the nginx server more difficult to extend and customize than G-WAN, despite nginx's source code availability.

Security

Since its initial release in 2009 G-WAN has been used on trustleap.ch and gwan.ch (using Windows 2003 until October 20th, 2010 and Linux Debian since then). No security hole has been found so far, despite constant attacks, sometimes coordinated from well-connected Data Centers.

In the last two years, nginx has exposed users to 8 security holes, 6 of them being rated 'major'.

G-WAN being used on only a few handful of servers vs the 5% of nginx market share, nginx might have attracted more hackers. And the source code availability of nginx might have helped them to find obvious vulnerabilities by just using static code analysis tools.

On another hand, G-Wan seems to crystalize the ire of whatever dared to call itself a server. The censorship, attacks and vandalism directed against it reflect the levels of its competitors' frustration for being unable to match G-WAN's features, ease of use and performances.

In October 2011, multiple vulnerabilities have been found in G-WAN. According to the security researcher, the vendor refused to cooperate or acknowledge the issues. The issues seems to be resolved in the latest version.

Performances

Because nginx is using several processes to scale, it necessarily duplicates allocated resources and requires inter-process communication. This overhead is visible in benchmarks where CPU and memory resources grow with the number of worker processes involved in the task of handling incoming connections.

G-WAN, by contrast, is using one single process. This design choice lets G-WAN use hardware more efficiently and consume far less CPU than nginx for the same tasks. When serving static contents G-WAN uses less than 4% of the CPU, while nginx can use more than 50%.

By not starving the OS kernel G-WAN achives much better performances with both static and dynamic contents than all other Web servers, nginx included: independent benchmark comparing G-WAN to Lighttpd, Nginx, Nginx + Varnish (Stackoverflow's and Facebook's "Web server Accelerator"), Apache Traffic Server (Yahoo!'s "Web server Accelerator").

When G-WAN's author discovered Nginx's memory usage which hardly differs, he publicly praised Igor (Nginx's author) for this unique feat and immediately took action to outdo Nginx in this matter: G-WAN v2.4+ now uses half of Nginx's memory (~5 MB for 4 workers) - despite producing dynamic contents (this must be compared to the footprint of Nginx + PHP).

For the first time in history, a Web server (G-WAN) is faster on Windows than Microsoft IIS 7 (which has an 'unfair' advantage by running in the Windows kernel).

Having proved its value on Windows, when ported to Linux G-WAN also became the fastest Web server on Linux, demonstrating the value of its design.

Being the fastest on both platforms gave G-WAN the credibility to compare Linux to Windows and G-WAN/Linux is massively faster than G-WAN/Windows, illustrating the extraordinary value of the (free) Linux kernel.

Interfaces

Interfaces are necessary to extend the features of a server.

Backends

G-WAN supports SCGI and Reverse-Proxy features via (~100-line) C/C++/Objective-C script Handlers (the equivalent of nginx modules, just much simpler to implement thanks to BSD socket calls that behave asynchronously behind the scene but which can be used by G-WAN scripts and existing third-party compiled libraries like if they were blocking).

A native nginx module supports fastCGI, while SCGI and WSGI are supported via third-party modules. The backend process must be installed, configured and run separately.

Memcached

Nginx supports memcached natively.

G-WAN's own cache (based on its ultra-fast KV store) is much faster than memcached but the memcached library (like any other existing library) can be used directly by G-WAN scripts via the '#pragma link' directive (without any interface or dedicated module).

Further, G-WAN has released a Key-Value Store which inserts 100 million keys per second and searches those keys almost twice faster than it inserted them[1].

This Key-Value store is faster than Tokyo Cabinet TC FIXED (a fixed size array) and scale much better since it is 'wait-free' (no locks and no delayed job queues).

X-Sendfile

The X-Sendfile HTTP header allows scripts or Web applications to send static files that stay under control of the Web server. nginx does not support X-Sendfile and implements a similar feature using the X-Accel-Redirect HTTP header which retricts access to relative file paths from a predefined location.

G-WAN scripts can create files under the server root directory (or use cached entries in its KV store) and then tranparently point clients to them, defeating the need for the X-Sendfile feature in the first place (and behaving much faster by waving all the overhead associated with unecessary HTTP headers injection and parsing as well as communication between the server and a script engine).

Modules

nginx modules (like Apache modules), let developers extend the server features but nginx interfaces are as rich as they are complex and certainly not for the faintheart.

G-WAN lets you do much more with much less: you don't need to become an expert because G-WAN provides one single entry point and hides the complexity of things like asynchronous client requests behind standard BSD socket calls (even for existing compiled libraries), allowing you to write procedural code that scales like event-driven code.

The Flash Player is able to tell a Web server from which position a movie should be downloaded. This is implemented as pre-compiled C modules by Apache (137 lines of code), Lighttpd (352 lines) and Nginx (257 lines).

The G-WAN flv.c script below is shorter, faster and easier to maintain than the corresponding Apache, Lighttpd or Nginx modules:

#include "gwan.h" // G-WAN exported functions

#define FLV_HEAD "FLV\x1\x1\0\0\0\x9\0\0\0\x9"

int main(int argc, char *argv[]) 
{
   char *query = get_env(argv, QUERY_STRING, 0); // query: "start=200000"

   if(!query || query[0] != 's' || query[1] != 't' // not a "start=" query?
   || query[2] != 'a' || query[3] != 'r' || query[4] != 't' || query[5] != '=')
      return 200; // HTTP status (200:'OK')
   
   http_t *head = get_env(argv, HTTP_HEADERS, 0); // set HTTP bytes range
   head->h_range_from = atol(query + sizeof("start=") - 1); // checked by G-WAN

   // insert the FLV Header
   http_header(HEAD_ADD | HEAD_AFTER, FLV_HEAD, sizeof(FLV_HEAD) - 1, argv);
   return 206; // HTTP status (206:'Partial Content')      
}

This handler is stored in /gwan/.../handlers/flv.c. Each host can have its own general-purpose handler (called main.c), or, like in the FLV case above, several content-type handlers (which name will just match the targeted MIME type).

Log Files

G-WAN and nginx support separate error logging per virtual server but, again, G-WAN does this (as well as log file rotation) without any configuration file.

License

Both G-WAN and nginx (2-clause BSD license) can be used for free by both open-source and closed-source projects.

Only nginx's source code is available. But given the way this code (and many other open-source projects) is written (lack of comments, overly complex design) many might be discouraged from even trying to learn anything. As G-WAN is closed-source, it is impossible to tell if its quality is as good as nginx's -other than comparing the size and speed of each code base, which remains a pertinent criteria.

Some said that as open-source players sell 'consulting' rather than 'licenses', to preserve revenues, it is therefore a temptation to make their products more complex than necessary and to distribute a continuous stream of critical patches. Open-source software players are generally under pressure to keep features and quality at high levels, as they are not dominant today in terms of market shares -except in the Web server area where Apache, Lighttpd and nginx (in alphabetic order) are more widely deployed than closed-source products (like G-WAN, Microsoft IIS, Lightspeed, Rock or Zeus).

Unlike other closed-source products, as G-WAN is not feature-limited and free for all, it can afford to take the opposite approach, seeking to be as simple as possible in everything, from installation to configuration and use, which may also help to explain the lack of security breaches. However, by not disclosing its source code, some insinuated that 1) G-WAN plans to make its product commercial in later stage (which is specifically denied in its FAQs page), or 2) its source code contains certain security/legal/etc issues that it is impossible to find (this is also denied on gwan.ch's front page).

And if audits matter, everything should be audited, from Linux, its updates and its drivers to the C Compiler used to build releases. On the top of that, source code audits have been proved pointless in 1984 by Ken Thompson's "Reflections on Trusting Trust". To a certain extend, this issue does not apply as much to G-WAN because G-WAN has full-control on its C script engine.

While performances (a good reason to choose a server rather than another, but a bad reason to choose one just because of it) help users to save money, expensive source code audits are reserved to those lucky ones who do not need the money (or can happily spend the money of others).

G-WAN has clearly been made for those who need to care about their budget -helping them to save on hardware, electricity and software licenses (G-WAN/Linux is massively faster than G-WAN/Windows).