G-WAN vs Nginx

From WikiVS, the open comparison website
Jump to: navigation, search
G-WAN Nginx
G-WAN
VS
 Nginx
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.

Nginx started in 2004 while G-WAN started in 2009.

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

While other servers rarely publish comparative benchmarks, GWAN Benchmarks (here vs Nginx) are driving its development as the authors' goal is to "harness the parallel processing power of the ever increasing number of cores available on each chip".

To advance the cause of reproductible research, G-WAN documents all its tests and provides a dedicated How-To and public-domain C source code.

Contents

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

G-WAN's architecture scales better on multi-Core CPUs... while using less memory.

[edit] Design

G-WAN aims at being super-fast without configuration, while offering "edit & play" scripts 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 - the audience targeted by G-WAN.

In contrast, Nginx has many traditional Web server features (like different sorts of configuration files and complex modules) which are more targetting Web Masters than Web developers.

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

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

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

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 is 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 more difficult to extend and customize than G-WAN.

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

Nginx has exposed users to several security breaches, with at least 8 of them being rated 'major'. That's, on average, a major vulnerability per year of existence.

An anonymous user, 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 this many times, the same self-proclaimed "neutral" editor uses multiple anonymous accounts to add it countless times to this Wiki page, under descriptions aimed at deceiving people by falsely asserting that the G-WAN author tried to hide the facts (while, on the contrary, he did the very opposite).

[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. This design choice lets G-WAN use hardware more efficiently and consume far less CPU than nginx for the same tasks.

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: G-WAN v2.4+ used half of Nginx's memory (~5 MB for 4 workers) - despite being also able to produce dynamic content (this must be compared to the footprint of Nginx + fastCGI).

[edit] History

In 2009, G-WAN v1 for Windows was faster than Microsoft IIS 7 (which had the 'unfair' advantage of running in the Windows kernel while G-WAN runs in userland).

Having proved its value on Windows, when ported to Linux in late 2009 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.

[edit] Interfaces

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

[edit] Backends

G-WAN supports SCGI and Reverse-Proxy features via (~100-line) 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).

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

[edit] Memcached

Nginx supports memcached via a dedicated module.

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

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

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

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.

PSEUDO-STREAMING

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

[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 a freeware, it is impossible to tell if the quality of its source code is as good as Nginx's - other than comparing the features/size ratio and the speed of each executable, which remains a pertinent criteria - and largely goes to G-WAN's advantage.

Unlike other closed-source products, as G-WAN is not feature-limited and it is free for all. G-WAN seeks to be as simple as possible in everything, from installation to configuration and use.

[edit] External Links

See Also the Following Articles

Retrieved from "http://www.wikivs.com/index.php?title=G-WAN_vs_Nginx&oldid=71378"
Personal tools
Namespaces
Variants
Actions
Navigation
Ads
Toolbox