4 ms·
If I had to speculate: - epoll, which was added to the linux kernel ~2002, makes it possible to hang on to potentially hundreds of thousands of concurrent conn
by RoboTeddy 17y ago
If I had to speculate:
- epoll, which was added to the linux kernel ~2002, makes it possible to hang on to potentially hundreds of thousands of concurrent connections on one machine. Just can't do that with threads/processes.
- the desire for real time web applications, which have to hold large numbers of concurrent requests (e.g. friendfeed)
- a focus on lowering web application latency, which can necessitate making data requests in parallel
- advances in software (such as gevent, mentioned below) that reduce the complexity of writing async software
- increasing use of remote services / slow requests over the internet (if you're working in a threading/process model, you'll need a process open for each concurrent request, which can become prohibitive)
- web applications are simply serving more requests than they used to be, and probably have more to gain from being asynchronous
Without async I/O operating a large modern web application would be a lot harder. Lots of huge sites rely on memcache, for example, which would suck if it didn't use event-based IO.
- ajross 17y agoI don't think all of those items are really arguments about I/O paradigms, though. Again, event stuff has been here forever, and clearly is appropriate for some tasks. But it's a tradeoff: you have performance needs you can't get from a simple implementation so you resort to the fancy tricks. So if you're writing the client handler for a database, or something like memcached, you need this technique (whether you need an abstraction library is another argument...). But most apps don't fall into those categories, and I'm not getting any of that vibe from this. It seems that a lot of people sincerely believe that this stuff is "easier" or "better" just because it has the fancy new Spicy Event Sauce. And the truth isn't like that at all, and in fact these are truths that we've all known for years now...
- hurt 17y agoHey ajross, do you know any good sources for reading up on different I/O paradigms? It's one of those things that I've read about different methods here and there, but I've never come across one good source that compared and contrasted the various techniques. The short answer may very well be no, since it somewhat depends on the programming language one chooses to use. As you'd likely handle I/O differently in something like Haskell, versus python. Anyway, I'm just curious Thanks.
- silentbicycle 17y agoFWIW, the C10K Problem page (http://www.kegel.com/c10k.html http://www.kegel.com/c10k.html) compares various approaches to handling tens of thousands of simultaneous clients. It's from 2006, but is a good overview of well-understood techniques. Also, some observations on server design from Jeff Darcy (http://pl.atyp.us/content/tech/servers.html http://pl.atyp.us/content/tech/servers.html).
- ajross 17y agoArgh... was just googling to find that link when you posted it. But yeah: this is the first attempt in the modern world to sit down and come up with a real guide to high performance I/O. Most of it is still relevant, though it was written before scary parallel SMP became common (8-way is routine for a server these days).
- silentbicycle 17y agoYeah. If you have any other links, please share. It wasn't too long ago when people were excited about fork-for-each-connection servers, though at least half of it was "OMG Unix system calls from Ruby" from people who probably don't know C. (That "* is Unix" meme.) Simpler approaches are good enough sometimes, though. There are plenty of services that won't ever need to handle more than a couple simultaneous connections, and that way you don't need to bother with asynchronous IO.
- hurt 17y agoThanks to you and ajross, this really helps.