[[Category:Software]][[Category:Free Open Source Software]][[Category:Proprietary Software]] {{Vs|G-WAN|Gwan-3.2.gif|http://gwan.ch|Nginx|Nginx.png|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 [http://wiki.NGINX.org/Main 8 years old] while G-WAN is not yet 2 years old. Using a radically different design, TrustLeap G-WAN claims that it is much faster than all others [http://nbonvin.wordpress.com/2011/03/24/serving-small-static-files-which-server-to-use/ a fact independently verified by third-party benchmarks]. Other servers do not publish comparative benchmarks. According to [http://gwan.ch/benchmark GWAN Benchmarks] this could be because they all have similar performance. Despite the comparative tests above made by Nicolas Bonvin, other communities sometimes argue that G-WAN is not benchmarked by third-parties or that its own benchmarks are biased. To remain neutral and foster reproducible research, G-WAN [http://forum.gwan.com/index.php?p=/discussion/525/webserver-scalability-varnish-NGINX-lighttpd-g-wan-rpscpuram documents all its tests] and provides [http://gwan.ch/source/ab.c public-domain C source code], allowing others to reproduce such benchmarks for themselves. == This article == Unlike all the other Web servers, G-WAN is systematically censored from Wikipedia despite ample third-party coverage. 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"... only after this fact was mentioned here. Any collusion would be accidental... if the [https://www.wikivs.com/wiki/User_talk:WikiAdmin "neutral" person in question did not ALSO ask this current Wikivs page to be deleted]. The WikiVS page that you are reading is constantly 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 history log). Demonstrating his "neutrality", this same vandal publicly calls [https://www.wikivs.com/wiki/User_talk:WikiAdmin "G-WAN a piece of shit"] while another calls for this same G-WAN article to be... [https://www.wikivs.com/wiki/User_talk:WikiAdmin "deleted like on Wikipedia"]. We have a pattern here: the same persons censor G-WAN from WikiVS and Wikipedia. Another outrageous F.U.D. campaign was about [http://gwan.ch/en_timeline.html#fredrik_widlund an alleged security issue initially posted by Fredrik Widlund], another vandal disguised as a 'security researcher' (while he never ever posted any other security advisory than his fake G-WAN advisory), and who created a blog where dozens of pages are entierely dedicated to denigrating G-WAN. It is remarkable that this fake security issue is recurringly used as an argument against G-WAN by [http://gwan.ch/blog/20120518.html Jarrod Mosen] (alias [https://www.wikivs.com/wiki/User:GWanBalancer "GWanBalancer"], alias [https://www.wikivs.com/wiki/User:SecurityMan "SecurityMan"], and [https://www.wikivs.com/index.php?title=G-WAN_vs_Nginx&limit=100&action=history who used the http://69.64.49.253/ "anonymizer" proxy server to claim he was not himself], going as far as to [https://www.wikivs.com/index.php?title=User:Pierre_Gauthier&action=edit&redlink=1 spoof Pierre Gauthier's identity], the author of G-WAN, to create an account dedicated to blank or insert insults in this article). This leaves little room for uncertainty regarding the agenda pursued by the censorship... which happens to hit dozens of times per day like [https://www.wikivs.com/index.php?title=G-WAN_vs_Nginx&action=history on May 29/30 2012 (24 times) and on July 18/19 2012 (26 times)]. Surprisingly, there no such a campaign against Nginx or any the of the technically-inferior servers that G-WAN [http://gwan.com/archives/g-wan_prez.pdf has benchmarked]. == 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 [http://gwan.ch/ a single process with a thread per physical CPU (or Core)]. - Nginx runs as [http://NGINX.net/ a master process and several worker processes]. But only G-WAN scales on multi-Core CPUs, [http://forum.gwan.com/index.php?p=/discussion/525/webserver-scalability-varnish-NGINX-lighttpd-g-wan-rpscpuram outperforming Nginx by a factor 4 (for static contents) on a 6-Core CPU]... while using 3 times less memory. == 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 a minimal set of innovative features (C, C++, Objective-C/C++, and Java 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 are more targeted to Web Masters than to Web developers. === 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 and Linux kernel 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). === Java, C, C++, Objective-C G-WAN scripts vs. Nginx Perl scripts === G-WAN natively supports Assembly, [http://gwan.ch/ ANSI C], C++, Objective-C/C++ and Java (which outperform other .Net C#, Java and PHP application servers by several orders of magnitude in speed and scalability). 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 [http://NGINX.org/en/ Perl scripts]. NGINX delegates 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/Java scripts are part of the G-WAN server (a single executable file of about 150 KB). Even with the Java VM loaded to execute Java servlets, G-WAN's footprint is a mere 20 MB. === Libraries === Any existing system or third-party library can be used directly by G-WAN C/C++/Objective-C/Java scripts - thanks to the G-WAN [http://gwan.ch/source/sqlite.c.txt "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 twd-industries.com 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. G-WAN being under massive attacks since its first day online, it has developed a DoS (Denial of Service) shield using its performance counters to detect when a TCP connection is not followed by an HTTP resuest, or when a request is split in many small parts, or read too slowly. In the last two years only, NGINX has exposed users to [http://NGINX.org/en/security_advisories.html 8 security holes], 6 of them being rated 'major', and NGINX has no defense against slow clients trying to exhaust the resources of the server. == 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. When serving static contents G-WAN uses less than [http://gwan.ch/en_linux.html 4% of the CPU], while NGINX can use more than 50%. By not starving the OS kernel G-WAN achives much better performance with both static and dynamic content, see this [http://nbonvin.wordpress.com/2011/03/24/serving-small-static-files-which-server-to-use/ 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 [http://nbonvin.files.wordpress.com/2011/03/mem2.png 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+ now uses half of Nginx's memory (~5 MB for 4 workers) - despite producing dynamic content (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 and implementation. Being the fastest on both platforms gave G-WAN the credibility to compare Linux to Windows and [http://gwan.ch/en_linux.html G-WAN/Linux] is massively faster than [http://gwan.ch/en_linux.html G-WAN/Windows], illustrating the extraordinary value of the (free) Linux kernel. == Interfaces == Interfaces are necessary to extend the features of a server. Here are the available options: === 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). NGINX modules support [http://wiki.NGINX.org//NginxHttpFcgiModule fastCGI], while [http://wiki.NGINX.org//NginxNgxSCGIModule SCGI] and [http://wiki.NGINX.org//NginxNgxWSGIModule 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 the need to write 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[http://forum.gwan.com/index.php?p=/discussion/comment/897/#Comment_897]. This Key-Value store is faster than Tokyo Cabinet TC FIXED (a fixed size array) and scales 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 [http://wiki.NGINX.org/NginxXSendfile 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 [http://www.evanmiller.org/NGINX-modules-guide.html 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 of code) - Nginx (257 lines of code) - G-WAN ( 18 lines of code). Due to its small size, we can public the G-WAN flv.c script below which is obviously 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. Further, even with log files, G-WAN is much faster than Nginx without log files. == License == Both G-WAN and NGINX ([http://NGINX.org/LICENSE 2-clause BSD license]) can be used for free by both open-source and closed-source projects. Only NGINX's source code is 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 comparing the size and 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.