
Threaded vs Evented Servers - khingebjerg
http://mmcgrana.github.com/2010/07/threaded-vs-evented-servers.html
======
klodolph
I 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))
    

or (perhaps typeset properly)

    
    
        t * 1000 / w

~~~
calibraxis
Clojure notation for me. In my view, it's a lot more appropriate for today's
programmer world than the traditional math notation, because computer parsing
is an issue. So I prefer the moldable Lisp version.

Many programmers dislike math notation; they have bad experiences of school,
and gloss over anything which reminds them of dull homework and tests. On the
other hand, programming notation symbolizes a feeling of freedom.

It helps that I'm more used to Clojure's notation than traditional math
notation. Also it's easily executable for me. No need to execute precise
arithmetic mentally; the computer can do it.

------
JulianMorrison
"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?

~~~
nkurz
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'.

~~~
mey
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.

~~~
klodolph
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.

------
kqueue
Event 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.

------
cgbystrom
Paul Tyma discusses some other myths regarding evented vs threaded servers:
<http://www.mailinator.com/tymaPaulMultithreaded.pdf>

~~~
tbrownaw
That looks interesting enough to post separately too:
<http://news.ycombinator.com/item?id=1546711>

------
sbov
This 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.

~~~
klodolph
Check out GHC's new IO manager. GHC, by default, uses non-blocking IO
exclusively and calls "poll" or some equivalent syscall to figure out which
green thread to wake up.

------
j_baker
The 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?

~~~
prospero
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 chained together.

However, you can counter-argue that the additional complexity isn't endemic to
the programming model, only certain languages. Also, in languages which
support multiple threads (read: not Javascript), a hybrid approach that uses
events where possible, and threads where necessary, may retain many of the
benefits of the event-based approach.

~~~
andrewvc
_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).

~~~
IgorPartola
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.

------
monos
Not specific to this article:

I find it unrealistic that threaded vs evented (or blocking vs non-blocking
I/O) comparisons always use a slow database server as the prototypical thing
to wait for.

I get that this is not the point but to a newcomer it must seem like "oh..
database servers are super slow, I must first and foremost worry about
optimizing access to them".

If your queries regularly take more then 10ms to complete, something is wrong
with the database (do caching, put database closer to querying server - maybe
even on the same machine).

~~~
e98cuenc
Whatever. >10ms is perfectly reasonable db access. Of course if your data is
small enough to fit in memory you will have much faster access time, but if
it's and you don't have a SSD, every disk seek will be at least 10ms and you
may need several to do all the queries needed to render a page.

------
known
<http://www.kegel.com/c10k.html>

