Is node. js best for Comet?

ArticleDirectory

• Is node. js the best comet solution?

If you are designing and selecting a comet server solution, this article will give you a more in-depth understanding of node. JS:

Personal Understanding:

1) For comparison between node. js and netty/Mina, the author thinks netty is more advantageous.

2) in C/C ++/nginx/memcache, node. JS, and netty. The author chooses netty.

Note: The comparison above does not indicate who is better than others. It can only be said that netty is more appropriate in the reverse push server architecture of the author.

 

Address: http://amix.dk/blog/post/19577#Is-node-js-best-for-Comet

At plurk we process using millions of comet communications ications PR. day and so far we have processed billions of them. it's comet at a very large scale and I think we are one of the biggest users of comet technology on the Internet. we use Comet to deliver realtime updates to the users so they can plurk in realtime with their friends.

Scaling this has been a challenge and we have tried divide different solutions:

• at first we used polling implemented in Python. this didn't scale that well and scaling this short term meant implementing polling in a C server. see my post for more: Fast polling using C, memcached, nginx and libevent
• after hitting limits with polling in C We calculated different comet solutions, but most of them were and still are very immature. so we implemented our own comet solution using Java and netty (a java. NIO network library ). see my post for more: plurk comet: handling of 100.000 + open connections
• then node. JS came along and I was a very big fan of it. after holding a presentation for Taipei open source group on node. js I rewrote our Java solution to node. JS and tried it out. it worked wonderfully and it used much less memory than our Java solution (around 10x less) and similar amounts of CPU.

our node. JS solution has served us well for the past 8 months and it has processed into millions of comet notifications each day. but sadly we began to have issues with processing our events and at our peak our comet queues got really huge.

We tried a lot of Optimizations to make node. js work-some of these were:

• Upgrading node. js to 0.2.2 from 0.1.33. Version 0.2.2 had worse performance and memory leaks-or at least the memory consumption had changed a lot for the worse
• Different code optimizations such as using optimized data structures
• Tried to rewrite using redis as a data store
• Tried to use a proxy for Channel writing

none of these worked and we eventually got some new hardware that fixed the problem somewhat. but given that we are a startup with limited resources throwing hardware at the problem isn't generally a solution we use that much.

So we revisited our old netty solution, did some optimizations to it and rolled it out in production. this was a win, it used more memory, but the general performance was much better. one netty server can currnetly handle around und 6000 comet communications PR. second to around 10.000 clients. the node. JS server cocould handle around und 500 PR. SEC (so it was at least an 10x improvement ).

Is node. js the best comet solution?

I wocould argue that it is if you just want a working solution ASAP. if you want something that is "Web-scale" then Java + Java. NIO is the way to go (or C/C ++ ). remember that node. JS served us well for the past 8 months serving millions of comet notifications each day. do also note that I implemented our node. JS solution in two days-so it's pretty simple to get something going with node.

but V8 (the Javascript VM that node. JS uses) has a serious problem and it's following:

• V8 does not support threads or processes-everything is handled by the main process, even garbage collecting

this limitation is a smart choice given that V8 is mainly intended to be used in browsers, but it's not that good in server ubuntures. the problem with our node. JS solution is that channel reads and writes and handled by the same process and this generally means that channel writing gets slowed down by channel reading and garbage collecting. separating them is easy in our Java solution since we can just run the channel writer in it's own thread, but with node. JS we can't do this.

as an end note I am still impressed by node. JS and its performance given how young the project is. I wanted to share your experience with it and with Comet in general. I hope you find this useful in your comet quest

Happy hacking.