For the ones interested in G-WAN + PHP: gwan.ch/blog/20121021.html
Announcement
Collapse
No announcement yet.
G-WAN Web Server Claims Speed Records, Features
Collapse
X
-
Originally posted by AnotherHumanBeing View PostFor the ones interested in G-WAN + PHP: gwan.ch/blog/20121021.html
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?
Comment
-
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.
Comment
-
Originally posted by uid313 View PostHe 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!
Originally posted by uid313 View PostNot the mention PHP support in G-WAN is useless. Just some basic core functionality works. It is not useful in the real world.
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.Originally posted by uid313 View PostPlus, isn't G-WAN just stolen nginx code with some marketing behind?
Comment
-
Originally posted by curaga View PostHe 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.
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.
Comment
-
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.
"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"
Comment
-
sdaf dssd
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)Last edited by johnj; 30 October 2012, 07:36 AM.
Comment
-
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.
Comment
-
Originally posted by russofris View PostI'm not saying Apache is perfect and Nginx is horrible, just that you present them a manner neither deserves.
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.Last edited by 0xBADCODE; 02 November 2012, 12:59 PM.
Comment
-
Originally posted by johnj View PostI 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.
Originally posted by johnj View Postit's quite obvious that "AnotherHumanBeing" is actually the author of G-WAN.
Comment
Comment