Live data from Hacker News

Threaded vs Evented Servers

mmcgrana.github.com

21–30 of 32 posts

Re: Threaded vs Evented Servers

#21

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

Exactly.. i got through the first few equations and then stopped reading.

Re: Threaded vs Evented Servers

#22
post #3

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?

This Usenix article argues that threaded servers are a better programming model, though it admits that evented servers with current setups may be more efficient (e.g. if there's no compiler support for minimizing per-thread stack overhead): http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.5.58...

Reply to myself since it's been too long to edit: Decided this was maybe worth its own submission -> http://news.ycombinator.com/item?id=1547353

Re: Threaded vs Evented Servers

#23
post #18

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.

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.

Re: Threaded vs Evented Servers

#24

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

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.

Re: Threaded vs Evented Servers

#25
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).

Re: Threaded vs Evented Servers

#27
post #25

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 c…

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.

Re: Threaded vs Evented Servers

#28

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

As someone who typically has a Clojure repl handy, I found it convenient to be able to copy-and-paste and play around with the model.

Re: Threaded vs Evented Servers

#29
post #3

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?

I think the answer is actually pretty straightforward. It's trivial to go from a serial to a threaded server. It's way harder to write an event-based server using poll or select. Serially: int handle_connection(int fd) { ... } int loop() { ... while(1) { fd = accept(listener); handle_connection(fd); } } Threaded: int handle_connection(int fd) { ... } int loop() { ... while(1) { fd = accept(listener); thread_start(han…

No its not. Using your contrived limited example its even less code.

Evented:

  int handle_connection(int fd) {
    ...
  }

  int doaccept() {
      put_on_event_loop(accept(listener));
  }

Re: Threaded vs Evented Servers

#30
post #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 reque…

False.

An evented server (at least, until they get a lot fancier and make you program with locks and such) only gets to use one of the cores, while a threaded server gets all four.

Using a single core just means that the threaded server doesn't get any advantage from being threaded, while the evented server gets everything it can use.

This "model" is worthless for comparison.

Post reply on HN