Understanding the code inside Tornado, the asynchronous web server • Hacker News Board

Re: Understanding the code inside Tornado, the asynchronous web server

#41

Post by ankrgyl » Sun, May 08, 2011, 10:46 PM UTC

jrockway wrote: post #35

ankrgyl wrote: post #15

Earlier quoted context omitted.

Even with Python (CGI backed by Apache), you can scale with threads. The issue of scaling with threads vs. events is a pretty hot debate, and I think the author sets up this kind of criticism by addressing it poorly. Personally, I fall into the event-driven camp, because it involves the operating system as little as possible (only file descriptors). The C10K link has a great overview of the threaded approach ( http:/…

Well, actually, it involves the operating system rather heavily. select, epoll, kqueue, etc., etc., are not user-space things, after all, and if the OS implementation is bad, you are going to run into trouble.

Yes, they of course involve the OS, but are much lighter than overhead from spawning a thread. Furthermore, what's the point in considering bad OS implementations? Linux is free and does a good enough job, so that should be the baseline for considering performance.

Re: Understanding the code inside Tornado, the asynchronous web server

#42

Post by ankrgyl » Sun, May 08, 2011, 10:54 PM UTC

cdavid wrote: post #25

ankrgyl wrote: post #15

Earlier quoted context omitted.

Even with Python (CGI backed by Apache), you can scale with threads. The issue of scaling with threads vs. events is a pretty hot debate, and I think the author sets up this kind of criticism by addressing it poorly. Personally, I fall into the event-driven camp, because it involves the operating system as little as possible (only file descriptors). The C10K link has a great overview of the threaded approach ( http:/…

Another issue with evented frameworks in python is that you have to ensure nothing is blocking anywhere in your code, which becomes harder the more complex your application becomes. People will often mention IO, database, etc... forgetting that it is also an issue if your request handler takes CPU for N ms (e.g. encoding a relatively large payload in json, etc...). everything needs to be written with async in mind. L…

I don't think of this as a problem. Tornado is just a small and lightweight non-blocking HTTP server with a couple of convenient libraries. There are some pretty awesome, elegant solutions to the problem you point out, and I like to think of these as extensions to the small Tornado framework.

One really cool one is http://thomas.pelletier.im/2010/08/websocket-tornado-redis/, which demonstrates how to use threading to support Redis pub/sub.

For heavy computational tasks that aren't time-critical, you could have an accessory worker thread that chugs queued computations (yay first-class functions) in computational downtime.

Re: Understanding the code inside Tornado, the asynchronous web server

#43

Post by ankrgyl » Sun, May 08, 2011, 10:58 PM UTC

barrkel wrote: post #32

_delirium wrote: post #31

Earlier quoted context omitted.

That's essentially the thesis of this 1978 paper, though they group evented programming under the broader "message-passing" style: http://www.sics.se/~adam/pt/duality78.pdf

Indeed. And the corollary is that every possible performance benefit of non-blocking code is in principle achievable with threaded code, though some of the scheduler may need to be implemented in userland, with more explicit hinting of things like lifetimes of local variables in stack frames, etc., to get there. The true benefit of event-oriented network programming may be simply in what it makes explicit vs implicit…

Remember that modern implementations of kernel threads are designed to be general-purpose. So, while a threaded model would solve the problems, it also incurs necessary overhead (that works towards solving irrelevant problems). The event-driven approach can be thought of as minimalistic user-space threads for this context. Libraries like Python Eventlet (http://eventlet.net/) and CML (http://cml.cs.uchicago.edu/) are trying to reabstract this into the conveniences of thread-style programming.