G-WAN Web Server Claims Speed Records, Features

[AnotherHumanBeing]

For the ones interested in G-WAN + PHP: gwan.ch/blog/20121021.html

[uid313]

For the ones interested in G-WAN + PHP: gwan.ch/blog/20121021.html

It is bullshit.

He compares the performance of helloworld.php benchmarked on his server against a benchmark of a whole PHP framework compared by someone else on an entirely different machine with different configuration and settings. It says absolutely nothing!

Not the mention PHP support in G-WAN is useless. Just some basic core functionality works. It is not useful in the real world.

Plus, isn't G-WAN just stolen nginx code with some marketing behind?

[curaga]

He also contradicts himself.

First he claims to use PHP as a shared library. Then later it's exec'd for every request.

The numbers he cites are impossible. Fork + exec of a C hello world gets nowhere near a hundred thousand executions per second.

[AnotherHumanBeing]

He compares the performance of helloworld.php benchmarked on his server against a benchmark of a whole PHP framework compared by someone else on an entirely different machine with different configuration and settings. It says absolutely nothing!

I bet he just made a quick search for a PHP benchmark - somebody should send him a link to a helloworld.php on a similar machine, or better yet - wait till his next release with this rudimentary PHP support and do a 3rd party benchmark - as we have been asking phoronix guys to do with the static files webserver part.

Not the mention PHP support in G-WAN is useless. Just some basic core functionality works. It is not useful in the real world.

He is making the server for himself, to build his paid services on - so in his own words:

G-WAN C, C++, C#, D, Java and Scala scripts do better (in the 800k range), but remember that here G-WAN is using PHP in the worse possible way (by invoking it from the command line, doing absolutely no caching of any kind). In contrast, the other programming languages offer direct interfaces that allow to cache the pre-compiled code and to greatly limit the overhead involved in the transfer of their output – both things that are not allowed to PHP here ... It means that if the PHP community (users and providers) collaborate with G-WAN then this PHP support will quickly surpass today's G-WAN crude PHP draft interfacing ... I am not a PHP user. I will not be hurt if G-WAN makes C, C++, C#, D, Java and Scala scripts run at full-speed and not PHP. But given my sincere efforts to help the PHP community, this would be quite a waste of resources to bypass G-WAN now it has demonstrated that the savings for PHP users are unparalleled.

Plus, isn't G-WAN just stolen nginx code with some marketing behind?

Sure, because their features are almost identical Have you even been to their respective official pages, let alone tried them?

[skies]

He also contradicts himself.

First he claims to use PHP as a shared library. Then later it's exec'd for every request.

The numbers he cites are impossible. Fork + exec of a C hello world gets nowhere near a hundred thousand executions per second.

As I understand he is not fork()ing anything. Binaries are linked into the running server process using dlopen().

Being a C guy I did some evaluation of G-Wan, iirc asynchronous event-driven architecture (lock free) that allows it to scale very linear over multiple cores.

As it is closed-source (freeware) and the users code is loaded into the server process it is not possible to debug or tune your C/C++ code using gdb/idb and Intel vTune profiler. So in the end I did settle with the Monkey web-server for my projects as being able to work as a embedded webserver is a big pro beside pure performance.

Still could use G-Wan as a key-value store or for delivery of static content (html, images, css, js, etc) would be ok.

NGIX is overrated imho, don't know about Lighttp, haven't looked into that one.

[qeed]

The author of G-WAN often attacks people who say anything he doesn't like (such as author of nginx) and promotes his server on blogs and stackoverflow under dozens of aliases.


G-WAN Advisory – Multiple G-WAN vulnerabilities

A buffer overflow issue exists in the routine handling URL encoding for the "csp" (so called G-WAN servlets) sub-directory.
Exploiting the vulnerability results in remotely being able to execute shellcode on the system.

I reported the problems to the G-WAN developer, who began by very kindly thanking me for my effort and asked for the details.
After of course sharing all the findings, he returns after an hour claiming he can’t for his life understand what I mean.
Since there is no archive of old versions he will now pretend like it never happened. I find this reaction very sad.

The author claims the problems were solved independently a couple of days before being reported.

the URL parsing routines. There are actually, at least, three different implementations.
The HTTP/0.9 which did not terminate the decoded string and ended up being broken
The HTTP/1.0,1.1 static file implementation, which did not parse URL parameters at all
The HTTP/1.0,1.1 “csp” implementation, which contained the buffer overflow

MICROSOFT's Jihad against Efficiency

In MICROSOFT's "Mind Control" efficiency is a target of choice because it lets people buy less new machines (bundled with Windows licences).

In addition to the usual tricks to artificially inflate software (and MICROSOFT's revenues) the weapons they use in this holy war might surprise you, that is, if you are not part of the scam.

199,999 CHF to remove the "Server: G-WAN" header

"Source Code Insurance" - Get an encrypted source code archive for 7,999 CHF, and if anything happens to the developer, you will somehow "have access" to the key. (must also purchase 14,999 CHF/yr support)



G-WAN Captcha: "difficult or even completely impossible for robots"



It is, however, quite fast (sometimes) since it barely does any request processing or much of anything besides read/write and compile/execute "scripts"

[johnj]

I would recommend not ever running this program.

G-WAN Advisory – Multiple G-WAN vulnerabilities

A buffer overflow issue exists in the routine handling URL encoding
for the "csp" (so called G-WAN servlets) sub-directory. Exploiting the
vulnerability results in remotely being able to execute shellcode on
the system.

I reported the problems to the G-WAN developer, who began by very kindly thanking me for my effort and asked for the details.
After of course sharing all the findings, he returns after an hour claiming he can’t for his life understand what I mean.
Since there is no archive of old versions he will now pretend like it never happened. I find this reaction very sad.

The author claims the problems were solved independently a couple of days before being reported.

# curl localhost/..
Index of /..</pre>
<h2>Index of /..</h2>
<table width="94%">
[...]

# echo -e "GET /%31+%32=%33\r\n\r\n\r\n" | nc localhost 80
404 Not Found
[pid 20618] stat64("/gwan/0.0.0.0_80/#0.0.0.0/www/1+2=332=%33", 0xf7595cc0) = -1 ENOENT (No such file or directory)

# curl localhost/test?some=option
404 Not Found
[pid 20801] stat64("/gwan/0.0.0.0_80/#0.0.0.0/www/test?some=option", 0xf753ccc0) = -1 ENOENT (No such file or directory)

The author is also very hostile toward others and says bizarre things, from what I saw in a search. He also seems to use various aliases to promote and defend his software on stackoverflow and blogs... *ahem*

[johnj]

I made both of the above posts, but the first one wasn't showing up and I figured I was blocked for posting several links in my first post.

To add to my last post in case anyone hasn't figure it out, it's quite obvious that "AnotherHumanBeing" is actually the author of G-WAN.

[0xBADCODE]

I'm not saying Apache is perfect and Nginx is horrible, just that you present them a manner neither deserves.

You see, when one guy replaced his apache with nginx and I occasionally discovered this fact without watching server headers.

There was plain simple difference: at some point his server started serving static pictures faster than machinegun fires bullets while same server has been quite an average at that all the time. So I has been curious why it's performance skyrocketed like that. Small investigation of server headers shown that apache has been replaced with nginx. I never thought difference could be obvious like that so I can see it with naked eye. But it is. At least default apache worker (prefork) really suxx when it comes to serving a lot of static data quickly. No surprise nginx replaces apache in million of busiest sites here and there. And of course it's nice target to beat in any benchmark. Little series of experiments with siege, ab, apache and nginx shown it's really easy to beat apache on static files serving

P.S. and btw, we can see that even M$ with all their billions of dollars they can use for marketing brainwashing are seriously struggling and losing market here and there in favor of opensource servers. I find it very unlikely that some small upstart could anyhow gain noticeable market share with closed source server. There are already some closed servers like litespeed. Yet they have very marginal market share to say the least and it's not going to increase.

[AnotherHumanBeing]

I made both of the above posts, but the first one wasn't showing up and I figured I was blocked for posting several links in my first post.

Double posting is not such a bad problem compared to not getting your facts straight: gwan. com/en_timeline.html#fredrik_widlund

it's quite obvious that "AnotherHumanBeing" is actually the author of G-WAN.

I guess you don't need facts to prove that either? Did the same "trusty" sources told you that or you had a revelation this time?