If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

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.

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.

Originally Posted by uid313

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.

Originally Posted by uid313

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?

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.

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

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

sdaf dssd

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 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*

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.