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

Tornado: FriendFeed's non-blocking Python web server is now open source

bret.appspot.com

Post reply on HN
Print view View original

51–60 of 77 posts

Re: Tornado: FriendFeed's non-blocking Python web server is now open source

#51

Post by finiteloop »

n8agrin wrote: post #47

The templating system they developed looks pretty sweet http://github.com/facebook/tornado/blob/master/tornado/templ... . Just played around with it a bit and it's basically what I want: 1) Simple and clear syntax (e.g. they use 'end' not endfor, endblock, etc) 2) Assign template variables to anything (including functions) 3) Don't over-restrict the author (e.g. they allow list comprehensions in if tags) 4) Block and…

Thanks! Yah, the reason we rolled our own is because all the rest were so restrictive to authors. We didn't want a template system telling us what we should and shouldn't do in templates, so ours was a very thin layer on top of what basically translates directly to Python. It is actually one of my favorite parts of the system.

Re: Tornado: FriendFeed's non-blocking Python web server is now open source

#52

Post by poutine »

xal wrote: post #49
tiredandempty wrote: post #44

Earlier quoted context omitted.

how about turning this to a full framework? or is there one already?

I'll brainstorm the idea. I have some ideas of how to turn this evented programming into a very natural flow using ruby 1.9.1's fibers.

This would be extremely interesting as this area is one major weakpoint for available Ruby frameworks.

Re: Tornado: FriendFeed's non-blocking Python web server is now open source

#53

Post by simonw »

dlsspy wrote: post #43
finiteloop wrote: post #5

Earlier quoted context omitted.

How many deployed web apps really use Twisted? There are like 3 web packages in Twisted, most of which are really buggy, and as far as I could tell, barely used (even they acknowledge this, see http://twistedmatrix.com/trac/wiki/WebDevelopmentWithTwisted ). When we were developing this, we found that Twisted introduced as many problems as it solved in terms of incomplete features and bugs. The other protocols seem to…

"How many deployed web apps really use Twisted?" This is sort of the point. twisted isn't a web framework. It's a networking framework. I work on a lot of really awesome networking projects that either don't have web interfaces (various xmpp services) or have ones that need work (buildbot). Instead of filling an obviously missing hole in an existing framework, a new one was created that is missing all of the stuff th…

Tornado ships with an async HTTP client as part of the core framework.

Re: Tornado: FriendFeed's non-blocking Python web server is now open source

#54

Post by jnoller »

TimothyFitz wrote: post #48
jnoller wrote: post #22

Earlier quoted context omitted.

No, it doesn't. I/O bound tasks can heavily use multiple cores just fine using threads.

If you're CPU bound in pure-python computations then the GIL (Global Interpreter Lock) will cause you to only make use of one core. This is intentional: threads are hard, processes are simple.

I know that, except most web application servers spend most of their time in I/O - socket, database, etc. Threads are not hard: wanton abuse of shared state and concurrent modification of the shared state is hard to get right; tread a threaded app like a message-passing app and you have a much simpler life.

I'm intimately familiar with the limitations of python threads - and right now I'm the maintainer of the multiprocessing module, which is the process-based "reply" to the stdlib threading module.

Re: Tornado: FriendFeed's non-blocking Python web server is now open source

#55

Post by usaar333 »

cheriot wrote: post #37
usaar333 wrote: post #32

What exactly does 'non-blocking' mean in the context of a webserver?

Holding the TCP connection open does not tie up all the resources of the request handling thread. That way a large number of inactive connections can stay open.

Thanks. So to clarify, this is just the same as what lighttpd phrases as a 'select()-/poll()-/epoll() based web server'?

It seems that the main advantage of this is that you have one thread manging many sockets. I am a bit surprised that blocking kthreads would be so much slower relatively. What causes the slowness? Context switching? Additional stack memory usage?

Re: Tornado: FriendFeed's non-blocking Python web server is now open source

#57

Post by RoboTeddy »

DenisM wrote: post #50
RoboTeddy wrote: post #45

It seems like blocking calls to data sources (the database, memcache, etc) would screw with a lot of the benefits of running the framework asynchronously. If your Tornado processes freeze while making synchronous backend requests, you're gonna need a lot of them, which probably kills a lot of the value. Now all we need are async data clients that tie into the Tornado event loop, and a clean way to yield control back…

The browser-webserver delay resulting from long polling is much larger the frontend-backend delay. I think there is at least an order of magnitude difference there, hence an order of magnitude reduction is the amount of idle state kept on the server.

Yeah, I agree. For long-polling apps it seems like Tornado gives you a huge advantage.

For other web apps though, the frontend-backend delay is comparatively more important, because usually there's a load balancer or reverse proxy in charge of buffering up data arriving from distant/laggy browser connections and hitting the web application server with it all at once.

Re: Tornado: FriendFeed's non-blocking Python web server is now open source

#58

Post by kingkongrevenge »

usaar333 wrote: post #55
cheriot wrote: post #37

Earlier quoted context omitted.

Holding the TCP connection open does not tie up all the resources of the request handling thread. That way a large number of inactive connections can stay open.

Thanks. So to clarify, this is just the same as what lighttpd phrases as a 'select()-/poll()-/epoll() based web server'? It seems that the main advantage of this is that you have one thread manging many sockets. I am a bit surprised that blocking kthreads would be so much slower relatively. What causes the slowness? Context switching? Additional stack memory usage?

I don't think threads are slower or less scalable anymore. The OS threading systems have improved a lot over the last four years.

Re: Tornado: FriendFeed's non-blocking Python web server is now open source

#59

Post by agazso »

usaar333 wrote: post #55
cheriot wrote: post #37

Earlier quoted context omitted.

Holding the TCP connection open does not tie up all the resources of the request handling thread. That way a large number of inactive connections can stay open.

Thanks. So to clarify, this is just the same as what lighttpd phrases as a 'select()-/poll()-/epoll() based web server'? It seems that the main advantage of this is that you have one thread manging many sockets. I am a bit surprised that blocking kthreads would be so much slower relatively. What causes the slowness? Context switching? Additional stack memory usage?

You guessed right. Context switching is expensive, and the default stack size default is in the megabyte range. So if you want to have 10K connections open, it takes about 10GB memory. You can of course shrink the stack size, but you have to measure your programs stack usage before doing that and it is quite cumbersome.

With an event driven architecture you only have to hold the session information per connection in memory which can be as low as 4K, therefore you are able to maintain (depending on the complexity of the protocoll) n*100K connections.

The only drawback that you have to write and think your whole program event driven; you write callbacks for each io and timer operation and the control flow won't be clear if you read the program.

Re: Tornado: FriendFeed's non-blocking Python web server is now open source

#60

Post by dlsspy »

simonw wrote: post #53
dlsspy wrote: post #43

Earlier quoted context omitted.

"How many deployed web apps really use Twisted?" This is sort of the point. twisted isn't a web framework. It's a networking framework. I work on a lot of really awesome networking projects that either don't have web interfaces (various xmpp services) or have ones that need work (buildbot). Instead of filling an obviously missing hole in an existing framework, a new one was created that is missing all of the stuff th…

Tornado ships with an async HTTP client as part of the core framework.

It does, but from reading the code, it looks like it's closer to to twisted's getPage functionality. That's OK for things like Friendfeed's realtime API where you do long polls that return chunks of data and then process the data online and loop.

It's not OK for things like twitter's realtime APIs that provide infinite streams of data.

However, even in the case of friendfeed's API, I process the data incrementally. It's not uncommon for users of my service to receive data via xmpp before the http request has even completed.

I also use this technique for twitter's non-realtime APIs -- I use a pull-based SAX parser (that comes with twisted) to incrementally process the stream and collect and pre-sort the interesting parts. Then one of the callbacks I attach to the completion of the request (note one of: I have several that are reusable components) delivers the pre-sorted, pre-filtered results out via xmpp. I did this to reduce memory used in my daemon. It really helped.

So while it has one, it doesn't appear to be full-featured enough to work in my applications. And this is the sort of cause of confusion here. Twisted has a great network stack and a ton of really awesome protocol implementations sitting on the shelf (my apps mix http client and servers, xmpp, couchdb, dns, finger, etc...). What it doesn't have is a decent web framework.

One of the twisted guys, however, said it should be possible to transplant the web framework part of tornado onto twisted, so that would be great for the rest of us.

Post reply on HN