Live data from Hacker News

Twisted.web vs Tornado Performance, part deux

apparatusproject.org

21–30 of 38 posts

Re: Twisted.web vs Tornado Performance, part deux

#21
post #2

Innocently daft question coming up: As I understand, you can run web.py apps behind lighttpd, and the web server handles the processes. E.g. in lighttpd.cfg you can set {"max-procs" => 4} and I would see 4 instances of my web.py script running. But how is this done for a web-server done 100% in python? Python uses a GIL that only allows one thread to interpret bytecode at a time, so despite the amazing performance of…

See http://www.tornadoweb.org/documentation#running-tornado-in-p... . FriendFeed uses nginx as a reverse proxy to run several instances of the Tornado web server process. Each process has its own GIL.

Re: Twisted.web vs Tornado Performance, part deux

#22

I question the relevance of these tests. With all the attention being given to performance, everyone seems to be overlooking the fact that Tornado provides zero support for truly asynchronous web applications written for it. If you have any kind of long-running task to perform during a web request, you have to roll your own way of dealing with that task. To make it worse, the demos included with tornado that make use…

According to the Tornado documentation, FriendFeed runs many instances of the Tornado server. If the number of server instances is greater than the number concurrent requests, then there's no problem with blocking calls. I personally find synchronous code easier to write/debug/understand than Twisted deferred.

Re: Twisted.web vs Tornado Performance, part deux

#23
I guess i will never understand why they didn't choose twisted and finally gave it the revamped twisted.web it needs.. I have yet to see a more featurecomplete internet framework with which i can do practically everything the internet is about, with so much flexibility and yet it is suffering from the state of twisted.web. Aynchronous database access, http, pop3,imap,smtp, amqp, irc, msn and about every protocol out there can be so easily integrated in twisted, it amazes me everytime. Sad, that this framework isn't used more widely, it could rule the web.

Re: Twisted.web vs Tornado Performance, part deux

#24
post #4

Summary: * Mean response time -- Twisted.Web better than Tornado Average performances for Concurrent request: * @100 -- TW:Tor::0.50s:0.70s . TW better than Tor * @500 -- TW:TOr:: 3s:3.5s . TW slightly better than Tor * @1000 -- TW:Tor:: 5s:6.5s . TW better than Tor

This comparison makes me wonder what the upper limit is for python-based server performance. I wonder where the main bottleneck lies.

Re: Twisted.web vs Tornado Performance, part deux

#25

I question the relevance of these tests. With all the attention being given to performance, everyone seems to be overlooking the fact that Tornado provides zero support for truly asynchronous web applications written for it. If you have any kind of long-running task to perform during a web request, you have to roll your own way of dealing with that task. To make it worse, the demos included with tornado that make use…

Actually, I think their solution is pretty elegant; any task that takes that long is abstracted to its own HTTP request, which itself can be blocking without blocking the original request.

Re: Twisted.web vs Tornado Performance, part deux

#26
I still don't understand all of the fuss. These two are close enough in performance to where people should pick the framework that best serves their needs, their designs, and their brains.

Big deal -- there are now two ways (at least) to accomplish the same outcome in Python. Competition is good. I'm guessing that this will be a call to arms for the Twisted community and we'll see development accelerate.

At the same time, it is likely that a development community will form around Tornado. Great!

It's like people saying, when the Mac OS first launched, "Why didn't they just use DOS --it's there and it works." And yet the Mac OS has had a positive impact on operating systems produced by Microsoft. And Microsoft has impacted the Mac OS. It's all good.

And why is it that this same argument doesn't occur every time a non-async framework appears for python or other languages? What is it about the async nature that polarizes people? Maybe it's the fact that the both also start with the letter "T" and the name "Tornado" is a better named than "Twisted" (which implies increased complexity even if it isn't there...of course Tornados ultimately make a mess of things, so that's not it).

I, personally, am excited about Tornado. I think there's room for more than one player -- especially given the 'real time' direction the web is heading. And if this negatively impacts Twisted, then it'll be because Tornado has come up with an easier to understand approach and they'll benefit from being new and easy to grok -- in the same way Rails was once an easy-to-grok framework and that's what made it easy to understand.

The biggest winner, in my opinion, is the Python community and who doesn't want that?

Re: Twisted.web vs Tornado Performance, part deux

#27
post #7

Earlier quoted context omitted.

Given how common it is for production applications to be running in the cloud, this test is both valid and useful. Therefore these tests are much more meaningful than the first.

I disagree. If you run a test on a virtual machine then you are testing a lot of other software besides the software under test so the picture gets distorted. For instance, in the graphs that are in the report you can see a bunch of drops to '0' traffic, these suggest serious problems with the software under test. But knowing that the tests were done in a VM environment it is possible that the cause of these drops is…

If the tests were all over the map, I could agree with your original statement. But they are not. They are consistent.

Do you honestly expect anyone to believe that when test after test is run on a VM, and one framework consistently outperforms another, that this is due to the VM, and not the frameworks themselves?

Re: Twisted.web vs Tornado Performance, part deux

#28
post #27

Earlier quoted context omitted.

I disagree. If you run a test on a virtual machine then you are testing a lot of other software besides the software under test so the picture gets distorted. For instance, in the graphs that are in the report you can see a bunch of drops to '0' traffic, these suggest serious problems with the software under test. But knowing that the tests were done in a VM environment it is possible that the cause of these drops is…

If the tests were all over the map, I could agree with your original statement. But they are not. They are consistent. Do you honestly expect anyone to believe that when test after test is run on a VM, and one framework consistently outperforms another, that this is due to the VM, and not the frameworks themselves?

I'm more concerned with the drops to 0 and the overall throughput. The drops to 0 look quite bad, overall throughput is low compared to what I would expect from a setup like this.

Re: Twisted.web vs Tornado Performance, part deux

#29
post #17

I question the relevance of these tests. With all the attention being given to performance, everyone seems to be overlooking the fact that Tornado provides zero support for truly asynchronous web applications written for it. If you have any kind of long-running task to perform during a web request, you have to roll your own way of dealing with that task. To make it worse, the demos included with tornado that make use…

I think your point is really valid, though I think the relevancy of the tests were to test the claims made by Bret from tornado. Glyph made a really good point, tornado comes with zero automated tests... Ultimately after conducting these tests and listening to the discussion that has taken place, I am personally glad that we're writing our code with twisted.web

What are you writing with twisted.web?

Re: Twisted.web vs Tornado Performance, part deux

#30
post #29
post #17

Earlier quoted context omitted.

I think your point is really valid, though I think the relevancy of the tests were to test the claims made by Bret from tornado. Glyph made a really good point, tornado comes with zero automated tests... Ultimately after conducting these tests and listening to the discussion that has taken place, I am personally glad that we're writing our code with twisted.web

What are you writing with twisted.web?

Stay tuned :) !!!
Post reply on HN