"Finally, we’ll assume single-core servers"... isn't that rather like working out mathematically that the best gait for horses is hopping, provided you assume a one legged horse?
Threaded vs Evented Servers
11–20 of 32 posts
Re: Threaded vs Evented Servers
#12The examples given seem to indicate that evented servers are as fast or faster than threaded servers. If that's the case, why doesn't everyone just use evented servers?
First, the analysis relies on every step from request to response being evented, which in turn relies on the existence of event-based libraries for everything you want to do. Also, most languages don't have a good way of dealing with callbacks. They tend to make the code verbose and difficult to reason about. This is especially true for non-trivial applications, where there are more than two or three callbacks chaine…
First, the analysis relies on every step from request to response being evented, which in turn relies on the existence of event-based libraries for everything you want to do.
This is one of the main reasons I like node.js, EVERYTHING is evented, if it isn't it's probably a bug, or at least carefully explained why it can't be (and usually there's an async alternative).
Re: Threaded vs Evented Servers
#13Earlier quoted context omitted.
First, the analysis relies on every step from request to response being evented, which in turn relies on the existence of event-based libraries for everything you want to do. Also, most languages don't have a good way of dealing with callbacks. They tend to make the code verbose and difficult to reason about. This is especially true for non-trivial applications, where there are more than two or three callbacks chaine…
First, the analysis relies on every step from request to response being evented, which in turn relies on the existence of event-based libraries for everything you want to do. This is one of the main reasons I like node.js, EVERYTHING is evented, if it isn't it's probably a bug, or at least carefully explained why it can't be (and usually there's an async alternative).
IIRC it does not support things like the mysql lib because it is normally not event driven. So yes everything in node.js is event driven, but not everything you may need is included. Last I checked work was being done on it. The solution was to create a thread pool and treat communicating with it as an event driven protocol.
Re: Threaded vs Evented Servers
#14Event driven servers should not block on disk i/o, dns queries, or db calls [by using/writing async libs]. At least the well written ones. Else the Server Is likely to be dos-ed. The author is wrong in using a db call as an example. Secondly, the author totally ignored the time it takes to launch a thread vs not launching one at all in an event driven model and that affects the # of new connections/sec. Finally, switching between threads is not a very cheap operation since it causes a context switch, which directly affect the response time of the server.
Re: Threaded vs Evented Servers
#15"Finally, we’ll assume single-core servers"... isn't that rather like working out mathematically that the best gait for horses is hopping, provided you assume a one legged horse?
I think I agree. Perhaps if it was titled "Thread versus Evented single core servers" it would make much more sense. Having said that, there are ways to scale out to fill the cores for event based, and in some cases (ie nothing needs to be shared, would suit event based as IO bound) works just fine. There was an interesting article which I to me looked like it was uncovering that: http://dosync.posterous.com/clojure-nodejs-and-why-messaging...
Re: Threaded vs Evented Servers
#16"Finally, we’ll assume single-core servers"... isn't that rather like working out mathematically that the best gait for horses is hopping, provided you assume a one legged horse?
No, while this is a wonderful analogy, I don't think this is actually a problem. It's more like assuming horses weigh 1000 kg --- wrong for all but the biggest draft horses, but a nice round number to work with.
For the level of analysis in the article, there's really no difference between a 4 core machine and a processor with a 4x clock speed. His point is that the threaded model makes the most sense when each request is CPU intensive, and the event model works best when the work is light but the delays are long. All that would change for a multi-core processor is the definition of when the works starts to be CPU 'intensive'.
Re: Threaded vs Evented Servers
#17"Finally, we’ll assume single-core servers"... isn't that rather like working out mathematically that the best gait for horses is hopping, provided you assume a one legged horse?
No, while this is a wonderful analogy, I don't think this is actually a problem. It's more like assuming horses weigh 1000 kg --- wrong for all but the biggest draft horses, but a nice round number to work with. For the level of analysis in the article, there's really no difference between a 4 core machine and a processor with a 4x clock speed. His point is that the threaded model makes the most sense when each reque…
Moore's law is no longer in effect, it is cheaper to add more cores these days then add more speed.
Edit: My point is that, since we live in a real tangible world, where CPU power is being expanded by parallelism rather then increasing single pipeline throughput, we have to deal with that reality. To dismiss it to prove your point, seems a tad bit naive.
Re: Threaded vs Evented Servers
#18This article seems to focus on fairly heavy weight threads, but what about green threads? It seems like green threads with proper nonblocking libraries could behave performance-wise just like evented servers.
Re: Threaded vs Evented Servers
#19Earlier quoted context omitted.
No, while this is a wonderful analogy, I don't think this is actually a problem. It's more like assuming horses weigh 1000 kg --- wrong for all but the biggest draft horses, but a nice round number to work with. For the level of analysis in the article, there's really no difference between a 4 core machine and a processor with a 4x clock speed. His point is that the threaded model makes the most sense when each reque…
Moore's law is no longer in effect, it is cheaper to add more cores these days then add more speed. Edit: My point is that, since we live in a real tangible world, where CPU power is being expanded by parallelism rather then increasing single pipeline throughput, we have to deal with that reality. To dismiss it to prove your point, seems a tad bit naive.
Moore's law is about transistor count, not about speed. The increasing number of cores on a single die is predicted by Moore's law.
Re: Threaded vs Evented Servers
#20I would find it much easier to follow the article if the author used traditional mathematical notation instead of Clojure. Which do you prefer?
(* t (/ 1000 w))
t * 1000 / w