From WikiVS, the open comparison website

Jump to: ,

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.

Today, in Nov. 2010, NGINX is 8 years old while G-WAN is not yet 2 years old.

Using a different design based on threads and events, G-WAN is lighter and faster than the mainstream servers, a fact independently verified by several third-party (including academic expert) benchmarks over the years.

While other servers rarely publish comparative benchmarks, G-WAN Benchmarks (here vs NGINX and others) are driving its development as the author's goal is to "harness the parallel processing power of the ever increasing number of cores available on each chip".

The comparisons published by G-WAN seem to indicate that, if most HTTP servers do not publish comparative benchmarks, it could be due to the fact that they all have similar performance.

To advance the cause of reproductible research, G-WAN documents all its tests and provides public-domain C source code, allowing others to reproduce such benchmarks for themselves.

[edit] Censorship

Unlike all the other HTTP (and Application) servers, G-WAN is systematically censored from Wikipedia despite characteristics making G-WAN more "notable" than all others:

ample third-parties coverage,
zero-vulnerabilities,
unmatched performance,
very low CPU/RAM resources usage,
support of "edit & run" JIT scripted servlets in 2, 7, 15 and then 18 scripted programming languages.

Interestingly, the most recent G-WAN article deletion (for an article created on Thuesday March 8th by a Californian Wikipedia registered user) did not offer any "talk" opportunity and was available in the official Wikipedia "Deletion Log"... until this fact was mentioned here. An obvious collusion since the exact same "neutral" person in question also requested the deletion of this current WikiVS page.

The WikiVS page that you are reading is constantly erased and vandalised by G-WAN competitors – but at least G-WAN is not eradicated here (despite several attempts which blanked this page – promptly defeated by the WikiVS admin itself – see the part of its history log that we have saved).

Demonstrating his "neutrality" and technical arguments, this same anonymous vandal (operating under several nicknames and an IP-address anynomizer) publicly calls "G-WAN a piece of shit" while another called for this same G-WAN article to be... "deleted like on Wikipedia".

There's a pattern here: the same persons censor G-WAN on WikiVS and Wikipedia, using the same nicknames, and IP-address anonymizers: "Jarrod Mosen", alias "GWanBalancer", "SecurityMan", using the http://69.64.49.253/ "anonymizer" proxy server to claim that he was not himself, and going as far as to spoof Pierre Gauthier's identity, the author of G-WAN (acting here as "GwanModerator"), to create an account named "Pierre Gauthier" dedicated to blank or insert insults in the present article.

This leaves little room for uncertainty regarding the agenda pursued by this censorship... which happens to hit dozens of times per day like on May 29/30 2012 (24 times) and and on July 18/19 2012 (26 times).

Surprisingly, there are no such censorship and denigration campaigns against NGINX or any the of the technically-inferior servers that G-WAN has benchmarked.

[edit] Architecture

Both G-WAN and NGINX are asynchronous servers.

'Asynchronous' means that concurrency (serving several clients concurrently) is handled by a few request-handler instances (threads for G-WAN, processes for NGINX) handling many connections via event-loops. This approach differs from the method used by Apache which uses one single process and a thread for each new client request.

As each thread consumes memory resources to maintain its state (local variables, stack, CPU registers) 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 than the even older CGI approach (of one process by client request) 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

G-WAN's architecture scales better on multi-Core CPUs... while using less RAM and CPU resources.

[edit] Design

G-WAN aims at being super-fast without configuration and supports the whole HTTP/0.9/1.0/1.1 features, plus performance counters, multi-homing, virtual-hosts and aliases, throttling, etc., while offering "edit & run" JIT scripted servlets in Asm, C, C++, C#, D, Go, Java, Javascript, Lua, Objective-C, Perl, PHP, Python, Ruby and Scala (and a 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.

In contrast, NGINX has many traditional Web server features (like different sorts of configuration files and complex modules) which are more targetting Web Masters (used at paying for consulting telling which obscure options to use with wich values) than Web developers (more able to understand how repetivite and complex things could, and therefore should, be automated).

[edit] Protocol support

NGINX supports HTTP 1.1 and SPDY and the draft HTTP 2.0 implementation via NGINX-specific modules. HTTP 2.0 has so many by-design security and performance issues that many people, including Google itself (the authors of HTTP 2.0) doubt of its sustainability. HTTP 2.0 is likely to be replaced soon.

G-WAN also supports HTTP 1.1, but its protocol handlers are more flexible and make it far easier to plug third-party libraries (via the G-WAN "#pragma link" directive), so a larger number of protocols have been implemented, such as SCGI, FTP, DNS (TCP and UDP), SMTP and POP3, several database and key/value servers, and even a Level-2 (Ethernet) VPN.

NGINX, despite its funding and age, has never provided a so versatile development platform for programmers to quickly implement a wide range of network applications.

[edit] Configuration Files

Like most Web servers, NGINX uses configuration files that may look cryptic to newcomers as their syntax is incompatible with other servers. The rationale is that configuration files are needed to let users extract the best possible performances by tweaking server options. But the ever-growing number of options, and their sometimes obscure names is often an overwhelming obstacle for webmasters to change from a server product to another (that's the famous "lock-in" trick).

G-WAN does not use configuration files. Instead, users define Web sites, Virtual Hosts and Aliases by merely creating folders under the G-WAN root directory. As those folders must exist anyway to store contents, G-WAN considers that configuration files are redundant and error-prone, a nuisance.

[edit] Multi-language G-WAN scripting vs. NGINX fastCGI

G-WAN supports natively asm, C, C++, C#, D, Go, Java, Javascript, Lua, Objective-C, Perl, PHP, Python, Ruby, and Scala (which outperform other Web servers merely serving static contents, and other .Net C#, Java and PHP application servers by several orders of magnitude).

NGINX delegates dynamic content generation to other backend servers via interfaces (like fastCGI or SCGI) which must be installed and configured separately and which overhead is significantly consuming memory and CPU resources in addition to deliver lower performance and scalability.

By comparison, G-WAN scripts are part of the G-WAN server (a single executable file which footprint is about 250 KB).

Even with the Java VM loaded to execute Java servlets, G-WAN's footprint isa mere 20 MB (15 MB with C#).

[edit] Libraries

Any existing system or third-party library can be used directly by G-WAN 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 it has been done for the memcached library, NGINX requires a dedicated module to create an interface with a library. This is making the NGINX server much more difficult to extend and customize than G-WAN.

[edit] Security

Since its initial release in 2009 G-WAN has been used on a dozen of TWD websites (such as 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.

Like for performance, it has been often falsely asserted that this was due to the fact that G-WAN (supposedly) had less features that NGINX, which is incorrect: as an application server, G-WAN supports "edit & run" JIT scripted scripted servlets in 15 programming languages, a Key-Value store, an email client, GIF I/O, 2D drawing, charts and sparklines, crypto, RNGs, etc.

G-WAN being under massive attacks since its first day online, it has developed a DoS (Denial of Service) shield based on adaptive timeouts reporting attacks in log files in 2010. This feature used G-WAN performance counters to detect when a TCP connection is not followed by an HTTP request, or when a request is split in many small parts, or read too slowly.

NGINX, in contrast, has exposed users in the last two years only to 8 security holes, 6 of them being rated 'major'.

So far, NGINX has no defense against slow clients trying to exhaust the resources of the server, and this is even a requirement for the NGINX wrk benchmarking tool: it takes a long time to establish hundreds of thousands of TCP connections before sending the first HTTP request. This hits the G-WAN DoS shield that closes these idle connections, leading to what wrk reports as 'timeouts', a strange choice (Web browsers do not operate this way) that can be falsely interpreted as the inability of G-WAN to scale (while G-WAN timeouts can be extended to cover this case, either globally or on a per-connection basis).

The NGINX official website claims that it has exposed its customers to several security breaches, with (at least) a dozen of them being rated 'major'. That's, on average, more than a major vulnerability per year of existence... BUT this official NGINX page for security advisories ommits 90% of the NGINX vulnerabilities listed on the official U.S. Government CVE list, raising questions about its value as a reliable source of information.

An anonymous user (also using the TOR anonymizer network, see the page history), insists to use a fake advisory that has been exposed since day one on G-WAN's site as a fake, written by a self-proclaimed security expert that never wrote any other advisory, on a blog entirely dedicated to trashing G-WAN. Despite having been explained in lengthly details that this information is purposedly erroneous and misleading, the same self-proclaimed "neutral" editor used multiple anonymous accounts to add it countless times to this Wiki page, under descriptions aimed at deceiving people by falsely asserting that G-WAN tried to hide the facts (reading the link above makes it obvious who was doing what).

[edit] Performance

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, uses one single process (with one thread per CPU core, each handling an event-loop). This design choice lets G-WAN use hardware more efficiently and consume far less CPU than NGINX for the same tasks.

The G-WAN implementation is also superior, a task which is trivial to check by implementing the G-WAN loan.c servlet example as an NGINX module (and by measuring only the time taken to format the reply, in addition to the time to serve the server response payload with its HTTP header).

By not starving the OS kernel G-WAN achives much better performance with both static and dynamic content, see this independent benchmark comparing G-WAN to Lighttpd, NGINX, NGINX + Varnish (Stackoverflow's and Facebook's "Web server Accelerator") and Apache Traffic Server (Yahoo!'s "Web server Accelerator").

When G-WAN's author discovered NGINX's low memory usage, he publicly praised Igor (NGINX's author) for this unique feat and immediately took action to also outdo NGINX in this matter, proof that a sane competition is productive and can lead to improving technology, that is, if the players feel that a challenge is stimulating their creativity (rather than triggering their lowest instincts).

As a result, G-WAN v2.4+ used half of NGINX's memory (~5 MB for 4 worker threads) – despite being also able to produce dynamic content (this must be compared to the footprint of NGINX + fastCGI + a backend Java or PHP application server).

[edit] History

In 2009, G-WAN v1 for Windows was 4 times faster (for a 100-byte file) than Microsoft IIS 7 (which had the 'unfair' advantage of running in the Windows kernel while G-WAN runs in userland), and thousands of times faster for dynamic contents.

Microsoft has then setup a conference-call with 5 of its directors to acquire a source code license of G-WAN. But the director the Microsoft IIS (Internet Information Server) division rejected the possibility of a deal, having previously spent $7.5 billion to upgrade IIS v5 to IIS v7.

No less than 3 days later, Microsoft Windows "Defender", as well as the Microsoft VIA (Virus Information Alliance), erased G-WAN as a "virus".

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

These results 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 remarkable value of the (free) Linux kernel (the measured usermode overhead was 4 times higher on Windows than on Linux).

[edit] Interfaces

Interfaces are necessary to extend the features of a server. Here are the available options:

[edit] Backends

G-WAN, on the top of more than a dozen of native programming languages implemented as "edit and run" JIT scripted servlets, supports SCGI and Reverse-Proxy features via (~100-line) JIT (compiled on-the-fly) scripted 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).

NGINX modules support fastCGI, while SCGI and WSGI are supported via third-party modules. The backend process must be compiled, installed, configured and run separately.

[edit] Memcached

NGINX supports memcached via a dedicated module, compiled, installed and configured.

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 (the results were published on a forum maintained by a G-WAN user during 3 years; 3 consecutive G-WAN forums have been created, and each of them has been erased by the company hosting them).

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

[edit] 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 restricts access to relative file paths from a predefined location.

G-WAN scripts can apply any policy regarding file access, or even 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).

G-WAN has also added a return code (usually used for HTTP return codes) letting its scripts (whatever type of script: servlet, handler – and programming language) to send a file by just setting the reply payload to the name of the file.

This allows G-WAN servlets to implement their own caching (in memory or on disk, or on extern HTTP/SQL/KV backend servers) if they need to.

[edit] Modules

NGINX modules (like Apache modules), let developers extend the server features but NGINX interfaces are very complex and certainly not for the faintheart.

Following its financing, NGINX has released a significant selection of modules, both open source and commercial.

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 source code (or compiled libraries) that scales like event-driven code.

PSEUDO-STREAMING

The Flash Player is able to tell a Web server from which position a movie should be downloaded. This is implemented by:

Apache (137 lines of code for a pre-compiled C module),
Lighttpd (352 lines of code for a pre-compiled C module),
NGINX (257 lines of code for a pre-compiled C module),
G-WAN (18 lines of code for a JIT "edit & run" scripted C servlet).

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).

[edit] 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.

Further, even with log files, G-WAN is faster than NGINX without log files.

[edit] License

Both G-WAN and NGINX (2-clause BSD license) can be used for free by both open-source and closed-source projects. But only NGINX's source code is freely available.

As G-WAN is closed-source, it is impossible to tell if the quality of its source code is as good as NGINX's – other than by comparing their respective:

size,
speed,
features,
ease of use,
CPU and RAM resource usage,
number of vulnerabilities.

All these are pertinent criteria – and each of them largely weight to G-WAN's advantage as these slides illustrate it.

NGINX offers a "community" release and a "profesional" version.
G-WAN is not performance nor features-limited and it is free for all.

G-WAN seeks to be as simple as possible in everything, from installation to configuration and use.

G-WAN vs NGINX

Contents