4 ms·
"best" is a very subjective word. If we're talking about performance, I'd venture to guess it goes something like this: C > Java > Scala/Clojure> node.js > Py
by ericflo 16y ago
"best" is a very subjective word.
If we're talking about performance, I'd venture to guess it goes something like this:
C > Java > Scala/Clojure> node.js > Python > Ruby
But then there's all of the other tradeoffs, like how error-prone each environment is or how long it will take to code and debug in each language.
Note that Urban Airship recently did some research and found that Java with direct NIO code worked the best for them, not Netty: http://blog.urbanairship.com/blog/2010/08/24/c500k-in-action-at-urban-airship/ http://blog.urbanairship.com/blog/2010/08/24/c500k-in-action...
- cmelbye 16y agoWhy is Ruby last? EventMachine should work pretty well for most purposes I think.
- moe 16y agoEventmachine can juggle connections fairly well, but the common MRI problems kick in once you start actually doing something with these connections. Namely heap fragmentation followed by unbounded heap growth which results in stop&go operation during gc runs - until the host eventually swaps to death. Other ruby impls (REE, JRuby or rubinius) might be better in those regards. But I wouldn't trust MRI with a long running process that might get under anything but the lightest pressure.
- pmjordan 16y agoIt also heavily depends on what kind of state you're maintaining, whether any of it needs to be persisted or shared across connections, and how much CPU load the processing outside of pure connection handling will produce. Having a suitable scalability mechanism may be worth more than reduction of per-connection-event CPU cycles. (scaling beyond more than one core, scaling beyond more than one server)
- amix 16y agoI think the ultimate perfomance is found in pure java.nio/C/C++ solutions, but I think having a bit slower perfomance and higher abstraction is better since it makes it much easier to maintain and debug the system. My general impression of java.nio is that it's very low-level and a generally hard to code against and it's the main reason why we didn't choose it. This said, I think node.js offers great usability while perfomance is pretty good. So if I was developing a new comet solution I would give node a go - you can always rewrite to something more low level once you begin to hit limits. IMO going after java.nio directly is a premature optimization and most projects won't hit limits with node.js.