There's no "G-WAN's Javascript engine". Just plain old V8 embedded via a handler. You get just the basics, no batteries included aka you need to code the bindings to various things (like FS, crypto, etc) by yourself.
A year ago, a member of the former G-WAN community wrote a handler and V8 wrapper: https://gist.github.com/1077769. Guess that the G-WAN author (Pierre) tweaked that a little bit more.
Tested it myself. For simple "hello world" it was 5.5x faster than node. Quite impressive given the fact that a new V8 context is created with every request. But, again, no batteries included.
That makes me all the more curious: why is it faster? I cannot imagine Node doing something obviously wrong that would explain the difference. Evented I/O is pretty well understood, I/O loops aren't that hard and it's all just accept()/read()/write()/close() at the end of the day. Where does the 5x difference come from?
Wow, I didn't know that. I certainly did not expect to find that information in the FAQ. In fact this is the first time I've heard of a web server doing that.
So was the benchmark the author posted with microcaching turned on? While it's a legit way to reduce the load in real-world situations, it feels a little like cheating when used in a benchmark.
A year ago, a member of the former G-WAN community wrote a handler and V8 wrapper: https://gist.github.com/1077769. Guess that the G-WAN author (Pierre) tweaked that a little bit more.
Tested it myself. For simple "hello world" it was 5.5x faster than node. Quite impressive given the fact that a new V8 context is created with every request. But, again, no batteries included.