Node and Scaling in the Small vs Scaling in the Large
1–10 of 66 posts
Re: Node and Scaling in the Small vs Scaling in the Large
#2Despite whether you agree with him or not, Alex is one of the best technical writers around. This post is exemplary of that.
Re: Node and Scaling in the Small vs Scaling in the Large
#3I'm glad to see people starting to push back against the cult of “Evented is faster.”
It may be, it may not be. The idea that it always is, though, that's balderdash.
Re: Node and Scaling in the Small vs Scaling in the Large
#4I'm glad to see people starting to push back against the cult of “Evented is faster.” It may be, it may not be. The idea that it always is, though, that's balderdash.
It's just obvious how "threaded" can be slow even in low scale scenarios. It's less obvious how evented can be slower than the hardware allows (not saying it can't be). If nothing is known about the large scale, it still looks like a clear win for evented.
Re: Node and Scaling in the Small vs Scaling in the Large
#5I'm glad to see people starting to push back against the cult of “Evented is faster.” It may be, it may not be. The idea that it always is, though, that's balderdash.
It's just obvious how "threaded" can be slow even in low scale scenarios. It's less obvious how evented can be slower than the hardware allows (not saying it can't be). If nothing is known about the large scale, it still looks like a clear win for evented.
I keep hearing assertions that threaded can be slow or does not scale. Can somebody describe the reasons here or point to a good document on the subject?
I often see "scalable" and "fast" used interchangeably in these discussions. These are different concepts. Is the contention that threading is not as scalable as evented, not as fast as evented, or both?
Re: Node and Scaling in the Small vs Scaling in the Large
#6Excellent piece of writing.
I haven't done a whole lot of concurrency programming, so before reading this article I didn't realize that the events vs. threads debate is still being had. The example that Ryan Dahl likes to use to illustrate the superiority of the event model whenever he talks about Node is nginx vs. Apache. That example did more in my mind to reinforce the idea of events being superior to threads (in terms of speed and memory consumption) than anything else.
Keep in mind when reading this article that Alex recently left a little company called Twitter. It's safe to say that relatively few companies will ever have to scale the way that Twitter has.
Re: Node and Scaling in the Small vs Scaling in the Large
#7I'm glad to see people starting to push back against the cult of “Evented is faster.” It may be, it may not be. The idea that it always is, though, that's balderdash.
"It may be, it may not be."
Exactly. As he mentions, engineering any given system presents its own unique set of challenges, and should be addressed as such.
Use the proper tools to solve problems. There are no one-size-fits-all solutions in science. Computer or otherwise.
Re: Node and Scaling in the Small vs Scaling in the Large
#8Really great piece; definitely a great writer even in a heavily technical piece like this.
Interested to al3x's thoughts on the RoR vs. Python-Django also.
Re: Node and Scaling in the Small vs Scaling in the Large
#9I'm glad to see people starting to push back against the cult of “Evented is faster.” It may be, it may not be. The idea that it always is, though, that's balderdash.
As he notes, evented vs threaded is only important within a single machine.
I would argue that your architecture for distributing load across machines is more important than evented vs threaded. If we think that the difference in performance is small (regardless of which is faster,) then the question becomes one of which programming style you prefer. Node's implementation of events means you can have mutable state without worrying about locks or synchronization blocks or whatnot.
Re: Node and Scaling in the Small vs Scaling in the Large
#10Earlier quoted context omitted.
It's just obvious how "threaded" can be slow even in low scale scenarios. It's less obvious how evented can be slower than the hardware allows (not saying it can't be). If nothing is known about the large scale, it still looks like a clear win for evented.
I keep hearing assertions that threaded can be slow or does not scale. Can somebody describe the reasons here or point to a good document on the subject? I often see "scalable" and "fast" used interchangeably in these discussions. These are different concepts. Is the contention that threading is not as scalable as evented, not as fast as evented, or both?
Both threaded and event-driven I/O are scalable if you throw enough hardware at it and - all other things being equal - are about as fast.
The one-thread-per-connection model is conceptually simpler at the cost of a higher resource footprint, the event-driven approach adds complexity but allows you to process more concurrent connections.
Overly broad and simplified but that's about the gist of it. Like everything non-trivial, the real answer is: It depends.