Node.js powers comet for plurk (100k+ users at once)
amix.dk
amix.dk
- we use long polling, but will add WebSocket support once we get more browsers that support it. The code to make it work is shared here: http://amix.dk/blog/post/19489
- we had a smaller comet system in the past that was based on Java + JBoss Netty. It didn't scale that well (used ~10x time the memory node.js solution and had a lot of quirks, like lost connections). Generally thought Netty worked "ok", but I would recommend anyone doing anything serious to look at node.js
- node.js feels VERY natural, but it could be because I had coded so much in JavaScript :)
- I have done a presentation on comet with node.js+V8 to the Taipei Open Source Group which you can check out here: http://amix.dk/blog/post/19484
The technology is there to build next generation web-applications, what are you waiting for? :)
Also I would like to note I saw your Tornado vs Node.JS hello world test and it made me curious because we use Tornado and we really believed that it was the fastest.
So I looked at your results and noticed Tornado had 100x more bytes transfered in your AB test. So I decided to run your same test on a raw Tornado HTTP server (not using the web.py framework) and these were the results of Hello World.
These tests were ran on an 3.66 i7
Tornado (single instance):
import tornado.httpserver import tornado.ioloop
def handle_request(request): message = 'Hello Word' request.write("HTTP/1.1 200 OK\r\nContent-Length: %d\r\n\r\n%s" % ( len(message), message)) request.finish()
http_server = tornado.httpserver.HTTPServer(handle_request) http_server.listen(8009) tornado.ioloop.IOLoop.instance().start()
ab -c 100 -n 4000 http://127.0.0.1:8009/ Requests per second: 10037.84 [#/sec] (mean)
Node.js (single instance):
var sys = require('sys'), http = require('http'); http.createServer(function (req, res) { res.sendHeader(200, {'Content-Type': 'text/plain'}); res.sendBody('Hello World'); res.finish(); }).listen(8008);
ab -c 100 -n 4000 http://127.0.0.1:8008/ Requests per second: 9159.65 [#/sec] (mean)
However doing the test the way you did it did show the results you had with Tornado being 2x slower, however I don't believe that was a fair test at all.
Just my input.
His tested showed that Tornado was 2x slower the Node.jsbecause he did it wrong, I actually find Node.js rather impressive =)
Also regarding node.js we run around 8 I think and we plan to introduce more as node.js does not have threads or processes and currently our CPU and memory usage is very low. They are load balanced from our Python servers, but nginx would be a good load balancer as it's non-blocking.
It should be said that I have coded a lot in Python and I love Python - - so I don't have any bias and I would gladly use Python if it could scale.
http://axod.blogspot.com/2009/12/websocket-some-numbers.html
Also a caveat followup - websocket don't play nice with some proxies/nat/firewall setups. Either need https, or fallback on comet.
I think it's always good to have a few things on the go though, so I doubt I'd ever be 'full-time' on any one thing ;)
Edit: plus, I am confused about the presentation on comparison with Tornado slide. It seems Tornado has higher transfer rate. And after all, they just do a thin layer on top of epoll, what's the penalty here?
Redis http://github.com/fictorial/redis-node-client
memcache: http://github.com/elbart/node-memcache
MySQL support using DBSlayer
And it's fairly easy to implement other stuff using node.js's TCP module. This said, it could definitely use more modules, but it's a young project and I am sure they will come.
The second reason to pick JavaScript is that it's already geared towards event based programming, because of following things:
events in browsers and
closures are a natural part of the language, e.g.
document.addEventListener("click", function()...
Event based programming is needed to implement highly scaleable non-blocking servers. So JavaScript is a really good match...And really, JavaScript is a great language and it can emulate almost any paradigm that you may like. node.js also introduces a module system which makes it much easier to manage code. JavaScript isn't perfect and there's tons of bad code written for it, but it's possible to create beautiful code in JavaScript :-)
There seems to be some JavaScript support for Thrift, this would be a great way to have node.js fit in with ones architecture.
https://issues.apache.org/jira/browse/THRIFT-550
Also what are you using for your base libraries?
For example one needs RFC3339 date support, can you just plug in something like Google Closure Library?
(E.g. I'm a node.js newbie, but my understanding is that it doesn't have the io thread/worker thread pool, pipeline/handler framework that Netty does. Still reading about it.)
Did you need some other functionality, and also have you any interest of new modules for node?