Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why events are a bad idea for high-concurrency servers (2003) [pdf]

people.eecs.berkeley.edu

Post reply on HN
Print view View original

21–30 of 50 posts

Re: Why events are a bad idea for high-concurrency servers (2003) [pdf]

#21

Post by zzzcpan »

cryptonector wrote: post #18
cryptonector wrote: post #17

Earlier quoted context omitted.

C10K is another name for evented I/O, and it's from the 90s . By 2003 thread-per-client was already obsolete and known to be very bad. It's really quite simple: threads encourage the use of implicit program state via function calls, with attendant state expansion (stack allocation), whereas evented I/O encourages explicit program state, which means the programmer can make it as small as possible. Smaller server progr…

I don't normally care about downvotes, but if I give out a nice explanation and you don't like it, it'd be nice to get a reply. Was my response wrong? How? I might learn something from your response.

It's a trolling dogmatic paper. So of course some people will downvote you if you criticize the dogma.

Re: Why events are a bad idea for high-concurrency servers (2003) [pdf]

#22

Post by afcapel »

cryptonector wrote: post #17
pavlov wrote: post #2

Worth noting this is from 2003. The performance concerns of event-based servers have been greatly alleviated by both hardware and software advancements. The test setup used for this paper was a "2x2000 MHz Xeon SMP with 1 GB of RAM running Linux 2.4.20". Solid PC server iron for 2003, but basically equivalent to a $5/month server from Digital Ocean today. If you're looking to squeeze 100,000 concurrent tasks from tha…

C10K is another name for evented I/O, and it's from the 90s . By 2003 thread-per-client was already obsolete and known to be very bad. It's really quite simple: threads encourage the use of implicit program state via function calls, with attendant state expansion (stack allocation), whereas evented I/O encourages explicit program state, which means the programmer can make it as small as possible. Smaller server progr…

A context switch in a modern CPU takes only a few microseconds. A GB of RAM costs less than $10. So those concerns, although valid in theory, are usually irrelevant for most web applications.

On the other hand, simplicity in a code base usually matter. Code written with an evented API, littered of callbacks, is usually harder to read and maintain than that written in a sequential way with a blocking I/O API.

You can recreate a sync API on top of an evented architecture using async/await, but then you have the same performance characteristics of a blocking API, but with all the evented complexity lurking underneath and leaking here and there. Seems to me a very convoluted way to arrive to the point from where we started.

Re: Why events are a bad idea for high-concurrency servers (2003) [pdf]

#23

Post by Jweb_Guru »

zzzcpan wrote: post #12
notacoward wrote: post #9

Earlier quoted context omitted.

> The performance concerns of event-based servers have been greatly alleviated by both hardware and software advancements. Threads haven't exactly stood still in that time either, especially if you include green threads, fibers, coroutines, etc. > If you're looking to squeeze 100,000 concurrent tasks from that $5 server, this paper is relevant to you. It's relevant regardless, as part of a long-running back and forth…

I don't think there is back and forth anymore. Actual high performance research (e.g. when the cost of a single mutex is more than the whole CPU budget for processing something, like say a packet) has been devoid of threads since they got into the mainstream, so like for almost two decades already. They are still used, because this is what hardware and OS provide to do something on each core, but not for concurrency…

Sure, if you are devoting the whole computer to a single microbenchmark, threads a terrible idea. This is not necessarily the case when you have many heterogeneous applications running on a machine, though.

Re: Why events are a bad idea for high-concurrency servers (2003) [pdf]

#24

Post by cryptonector »

afcapel wrote: post #22
cryptonector wrote: post #17

Earlier quoted context omitted.

C10K is another name for evented I/O, and it's from the 90s . By 2003 thread-per-client was already obsolete and known to be very bad. It's really quite simple: threads encourage the use of implicit program state via function calls, with attendant state expansion (stack allocation), whereas evented I/O encourages explicit program state, which means the programmer can make it as small as possible. Smaller server progr…

A context switch in a modern CPU takes only a few microseconds. A GB of RAM costs less than $10. So those concerns, although valid in theory, are usually irrelevant for most web applications. On the other hand, simplicity in a code base usually matter. Code written with an evented API, littered of callbacks, is usually harder to read and maintain than that written in a sequential way with a blocking I/O API. You can…

A function call takes less. And using more RAM == thrashing your caches more == slowing down. The price of RAM isn't relevant to that -- this isn't about saving money on RAM but saving cycles. Yes, yes, that's saving money per-client (just not on RAM), but you know, in a commoditized services world, that counts, and it counts for a lot.

Re: Why events are a bad idea for high-concurrency servers (2003) [pdf]

#25

Post by nine_k »

afcapel wrote: post #22
cryptonector wrote: post #17

Earlier quoted context omitted.

C10K is another name for evented I/O, and it's from the 90s . By 2003 thread-per-client was already obsolete and known to be very bad. It's really quite simple: threads encourage the use of implicit program state via function calls, with attendant state expansion (stack allocation), whereas evented I/O encourages explicit program state, which means the programmer can make it as small as possible. Smaller server progr…

A context switch in a modern CPU takes only a few microseconds. A GB of RAM costs less than $10. So those concerns, although valid in theory, are usually irrelevant for most web applications. On the other hand, simplicity in a code base usually matter. Code written with an evented API, littered of callbacks, is usually harder to read and maintain than that written in a sequential way with a blocking I/O API. You can…

A GB of RAM only costs less than $10 if you are buying for your unpretentious gaming rig.

A GB of ECC server RAM costs more. An extra GB of RAM in the cloud can even cost you $10/mo if you have to switch to a beefier instance type.

Re: Why events are a bad idea for high-concurrency servers (2003) [pdf]

#26

Post by projektfu »

nine_k wrote: post #25
afcapel wrote: post #22

Earlier quoted context omitted.

A context switch in a modern CPU takes only a few microseconds. A GB of RAM costs less than $10. So those concerns, although valid in theory, are usually irrelevant for most web applications. On the other hand, simplicity in a code base usually matter. Code written with an evented API, littered of callbacks, is usually harder to read and maintain than that written in a sequential way with a blocking I/O API. You can…

A GB of RAM only costs less than $10 if you are buying for your unpretentious gaming rig. A GB of ECC server RAM costs more. An extra GB of RAM in the cloud can even cost you $10/mo if you have to switch to a beefier instance type.

That's true, if you're buying OEM ram for Dell or HP servers, it's more like $10-20/GB. However you can buy Crucial ECC DDR4 ram for $6/GB, so there's a hefty OEM markup.

Re: Why events are a bad idea for high-concurrency servers (2003) [pdf]

#27

Post by loeg »

cryptonector wrote: post #17
pavlov wrote: post #2

Worth noting this is from 2003. The performance concerns of event-based servers have been greatly alleviated by both hardware and software advancements. The test setup used for this paper was a "2x2000 MHz Xeon SMP with 1 GB of RAM running Linux 2.4.20". Solid PC server iron for 2003, but basically equivalent to a $5/month server from Digital Ocean today. If you're looking to squeeze 100,000 concurrent tasks from tha…

C10K is another name for evented I/O, and it's from the 90s . By 2003 thread-per-client was already obsolete and known to be very bad. It's really quite simple: threads encourage the use of implicit program state via function calls, with attendant state expansion (stack allocation), whereas evented I/O encourages explicit program state, which means the programmer can make it as small as possible. Smaller server progr…

Evented has some difficulties in practice:

* On Unix, only socket IO is really evented; this can be solved by using a thread pool (the Flash paper describing this problem and solution for httpds dates to 1999[1]) but is inelegant. This is the approach Golang takes behind the scenes.

* How to scale event loop work across cores; this can be solved, but adds complexity. In contrast, threads are quite simple to scale.

* How to share accept() workload across cores; this can be solved, too, but not portably. I.e. your 100 core server may very well be accept-limited if you have a single-core accept loop, or highly contend on a single socket object.

* Threadpools are definitely inappropriate if you have a ton of relatively idle clients (long-poll server, or even typical webserver), but are less wasteful if you have relatively few, always-busy clients.

I don't disagree that the synchronous threadworker design isn't the best choice for high performance services that can afford a lot of engineering time to design and find all the bugs. But thread-per-client is often a completely acceptable place to start.

[1]: https://www.usenix.org/events/usenix99/full_papers/pai/pai.p...

Re: Why events are a bad idea for high-concurrency servers (2003) [pdf]

#28

Post by cryptonector »

loeg wrote: post #27
cryptonector wrote: post #17

Earlier quoted context omitted.

C10K is another name for evented I/O, and it's from the 90s . By 2003 thread-per-client was already obsolete and known to be very bad. It's really quite simple: threads encourage the use of implicit program state via function calls, with attendant state expansion (stack allocation), whereas evented I/O encourages explicit program state, which means the programmer can make it as small as possible. Smaller server progr…

Evented has some difficulties in practice: * On Unix, only socket IO is really evented; this can be solved by using a thread pool (the Flash paper describing this problem and solution for httpds dates to 1999[1]) but is inelegant. This is the approach Golang takes behind the scenes. * How to scale event loop work across cores; this can be solved, but adds complexity. In contrast, threads are quite simple to scale. *…

These are minor things, and not really accurate, and at any rate, not relevant to the point that evented I/O == explicit, thus easy-to-minimize program state, while thread-per-client == program state expansion and costlier context switches.

Re: Why events are a bad idea for high-concurrency servers (2003) [pdf]

#29

Post by 7532yahoogmail »

Threads and events are duals. So it is possible to do both well if, in the threads case, the implementation is done right. The author makes the case he's done implementations well. The salient question then is: can the average programmer do threads based concurrent programming well? As dual, I think we can all agree that more effort/intelligence will lead to better solutions for threads or events.

Re: Why events are a bad idea for high-concurrency servers (2003) [pdf]

#30

Post by justincredible »

notacoward wrote: post #9
pavlov wrote: post #2

Worth noting this is from 2003. The performance concerns of event-based servers have been greatly alleviated by both hardware and software advancements. The test setup used for this paper was a "2x2000 MHz Xeon SMP with 1 GB of RAM running Linux 2.4.20". Solid PC server iron for 2003, but basically equivalent to a $5/month server from Digital Ocean today. If you're looking to squeeze 100,000 concurrent tasks from tha…

> The performance concerns of event-based servers have been greatly alleviated by both hardware and software advancements. Threads haven't exactly stood still in that time either, especially if you include green threads, fibers, coroutines, etc. > If you're looking to squeeze 100,000 concurrent tasks from that $5 server, this paper is relevant to you. It's relevant regardless, as part of a long-running back and forth…

> Those who do not learn the lessons of history...

have greater velocity?

Post reply on HN