V1

To bad that networks/proxies usually block websocket connections causing this solution to fail.

You could also just use Primus which exposes a Stream compatible wrapper by default for the client and server.

https://github.com/primus/primus

(Primus uses engine.io,sockjs,browserchannel,websockets internally so you're no longer locked into a specific framework)

Even Google is using it ;)

Thanks for you feedback, I did do some testing with multiple backends (4 different servers) but it didn't show any substantial changes. I'll see if I can do some in depth in a while.

I'll be more then happy to see if my configurations can be tweaked. And I was surprised as well, but it seems that it always boils down to the configuration files a small change can sometimes yield great results as seen with a specifying ciphers for SSL.

It's not a `local` server. The proxy, websocket server and the benchmark utility are all on different servers.

The `http-server-close` option did not change anything. But by adding the ciphers it was able to squeeze out the same performance as Nginx. I'll update the tests accordingly. Thanks for the heads up!.

hipache is build on top of http-proxy. That's why I haven't included it in the tests. They have seem to have switched to a fork of http-proxy but there aren't big (if any) performance modifications as far as i've seen from the commits.

I'll re-run the test with the advised changes and see if the performance improves.

Because we people obviously don't have a datacenter in our own basement. And the common mistake people make when benchmarking is running the servers on their own machine and then use the same machine to benchmark the server it's running.

You need to have multiple (powerful) machines for this. And also, spinning up machines in the cloud is quite easy to do and allows people to reproduce the same test results because you have access to exactly the same environment.

Are you referring to the cipher verification? I used:

  openssl s_client -host localhost -port 8082

Which is a openssl command. These settings were used for testing SSL: https://github.com/observing/balancerbattle/blob/master/ngin...

See https://gist.github.com/3rd-Eden/5345018 for the output of the openssl s_client for those ciphers. You'll see that `cipher : RC4-SHA` is used here. Which is one of the fastest if not the fastest cipher available.

Backed. Like everybody who touches JavaScript should do. Also. mmmm finally decent vim bindings for javascript?

I do wonder how it will compare to Eclipse Orion's JavaScript content assist which is using Esprima as parser.

http://contraptionsforprogramming.blogspot.nl/2012/02/better...

you can just as easily spawn multiple node.js servers and kill off the unresponsive one's

Great! Now everybody who wants to have information about Node.js has to scroll a shit load down and search for an oddly placed menubar on the right side..

Because who would expect a menubar with vital information such as docs above the fold?

But at least it's more visually attractive then the last version.

Socketpuppet #13242 reporting for duty sir.

It's great preso btw, did it get recorded?

Hi,

Could you describe was buggy about the demo? Did it load really slow or was it something else :)?

I'm currently working really hard on the commercial version of Observer which will be much more speedy less hacked up. So any feedback is still more than welcome at this point :D

Thanks,

Arnout (developer of Observer :D)

Lazy load it.

It's not the thing that users will be doing when they first load you page anyways.

Google Dart was designed to build large scale web applications, yet all their demos and example code only includes small applications. That still require quite a lot of code to build.

I don't see any profit of building a application in dart, if you have to create more code your self than you would with a regular HTML5 based application.

As this "Hello World" demo shows, the only thing It's good at is creating bloat and this will probably stay this way until native parsers are implemented.

\o/

Thanks, glad you liked it! I managed to pull it off thanks to a lot of planning.

Btw I won solo / overall (and also became first in utility) :)!

Hi,

I am going to continue working on it, the service still needs a lot of polish and tests (didn't have time to write those yet). It's most likely going to be paid service based on the amount recorded sessions. Or I'm going for a amazon based pricing module where you only pay for the sessions you record. I haven't decided on that yet, both models have it's pro's and cons.

If for some reason my attempt fails, I'll be open sourcing the complete service but I hope that never has to happen. But all the modules that I will be building during the development of the service will be open sourced, the glue that sticks it together won't ;)

It's probably because Chromium is shipping with a different WebSocket specification which isn't supported on some hosting providers yet.

Thanks, Glad you liked my entry. I personally think that Node's sweet spot is more real time than analytics. Analytics is just one of the things people want, in real time ;D

Yes I noticed that as well, but I found that the name observer really suited this service. But I'm still searching for alternate names to avoid potential confusion.

Yes I plan to continue development of this application after the competition, there are still some rough edges that needs to be fixed. So I see this a great working prototype to iterate on.

I still have some amazing ideas planned :)