G-WAN - High-performing HTTP server, scriptable using ANSI C | Hacker News Reader

G-WAN - High-performing HTTP server, scriptable using ANSI C

gwan.ch

7 pointscgbystrom8 comments

Open articleView on HN

Interesting?

✓ web server + ssl + dynamic content

✓ runs on linux

✓+ superlative performance claims

✓ free

☹ binary only download?

☹ no source?

☹ tenuous legal reasoning displayed on web site

No thanks.

(And I wish Unicode added the WTF glyph for posts like this. http://www.typophile.com/node/16343 )

The title of the website filled with keywords, making no sense at all isn't all that reassuring either.

The colorset also makes half the site unreadable.

That, and all of the above: no thanks.

This reminds me a lot of Litespeed, which was popular for a while before Nginx took over its market. It's hard to imagine very many people going back to that model.

It is good, however, to have occasional reminders that Nginx is not the be-all and end-all of Web server performance.

I wonder how fast nginx would be with C scripts for modules, rebuilding executables as needed using file mtime? Might be worth the experiment. For things like presence servers and COMET, it makes sense to code in C. Anyone else interested in exploring this subject?

Edit: Found this "comparison" http://www.wikivs.com/wiki/G-WAN_vs_Nginx which I suspect was written by the GWAN guy himself judging from the unusual sentence structure and phraseology. Independent confirmation necessary.

For things like presence servers and COMET, it makes sense to code in C.

I wouldn't assume that. Just using async I/O (e.g. Erlang, Node.js) instead of blocking I/O gives a huge performance advantage for those use cases, and if you need even more performance there are compiled-but-safe languages like Go (and maybe someday Rust). Due to its unsafe nature, I would leave C/C++ as a tool of last resort.

It's like not you're sharing needles with a heroin addict by using C. :)

Why does the site for this product read like it's trying to sell me age defying supplements?

Worth a quick eval but the site leaves a bad taste.

If my understanding is correct, rather than creating a new thread for each client request, it handles connections asynchronously, much like Nginx. But unlike Nginx, it uses only a single process, so it doesn't require any interprocess communication overhead. Too bad they don't release the source code.

Reply on news.ycombinator.com