Live data from Hacker News

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

bret.appspot.com

11–20 of 77 posts

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

#11

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…

The other protocols seem to have more attention than HTTP from what I could tell. I'm not sure even that is true. When I used twisted to write the justin.tv chat server (which is essentially an irc server) I gave up on twisted's irc protocol implementation and wound up just using twisted as an I/O layer.

Yah, that seems to be Twisted's problem. I think projects that don't have a real site using them day-to-day end up in this state often - lots of incomplete implementations of lots of features.

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

#12
post #9

Does this implement all of the HTTP 1.0 and 1.1 protocol specs? I'm kinda confused by the code :S

It implements a lot of HTTP/1.1, but see http://www.tornadoweb.org/documentation#caveats-and-support. In practice, we run behind an nginx reverse proxy, so we assume there are missing areas. We recommend people run in a similar fashion in production. We did not optimize for protocol completeness given our production setup.

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

#15
Awesome to see more Python webservers coming to light, and fast ones at that. One observation though; anyone else notice that the bar chart is a bit misleading? It compares running Tornado in 4 processes behind nginx to running Django behind Apache and Cherrypy as a single Python process. As a fellow coworker put it, "With 4 extra processes running of course it will be 4 times as fast." I'm not opposed to this kind of comparison when the intent is to show how configurations can increase req/sec, but if the intent is to compare one Pythonic webserver to another, this comparison seems a bit unfair. That said, assuming the "Tornado (1 single-threaded frontend)" measure is simply Tornado running as a single Python process, it still is plenty faster than Cherrypy.

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

#17
post #15

Awesome to see more Python webservers coming to light, and fast ones at that. One observation though; anyone else notice that the bar chart is a bit misleading? It compares running Tornado in 4 processes behind nginx to running Django behind Apache and Cherrypy as a single Python process. As a fellow coworker put it, "With 4 extra processes running of course it will be 4 times as fast." I'm not opposed to this kind o…

CherryPy is multi-threaded, so I am not sure what you are saying is correct. There are two types of servers: multi-threaded, multi-process. Tornado is multi-process. If your server is multi-threaded, it uses all of the cores without additional processes.

CherryPy did max out the CPU on all of the cores in the load test, so I think it was a fair test.

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

#18
post #15

Awesome to see more Python webservers coming to light, and fast ones at that. One observation though; anyone else notice that the bar chart is a bit misleading? It compares running Tornado in 4 processes behind nginx to running Django behind Apache and Cherrypy as a single Python process. As a fellow coworker put it, "With 4 extra processes running of course it will be 4 times as fast." I'm not opposed to this kind o…

Likewise, 4 extra processes does not mean 4 times as fast if you only have one or two cores on your machine. Check out the details at http://www.tornadoweb.org/documentation#performance for how we ran the test.

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

#19
This looks great. I'm likely to look at it a little more in the future. I've been using Second Life's asyncrounous coroutine library called eventlet. I've implemented most of my code with a good lightweight framework that fits; restish. On top of that, I use spawning to manage my server processes. I myself have seen these kinds of numbers with my own app tests.

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

#20
post #15

Awesome to see more Python webservers coming to light, and fast ones at that. One observation though; anyone else notice that the bar chart is a bit misleading? It compares running Tornado in 4 processes behind nginx to running Django behind Apache and Cherrypy as a single Python process. As a fellow coworker put it, "With 4 extra processes running of course it will be 4 times as fast." I'm not opposed to this kind o…

CherryPy is multi-threaded, so I am not sure what you are saying is correct. There are two types of servers: multi-threaded, multi-process. Tornado is multi-process. If your server is multi-threaded, it uses all of the cores without additional processes. CherryPy did max out the CPU on all of the cores in the load test, so I think it was a fair test.

[deleted]
Post reply on HN