[PhilChristensen]

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 of a relational database do all their queries in blocking fashion, which would render the server completely unusable during the runtime of every single query.

Given the fact that Twisted provides a robust API for dealing with long-running algorithms, as well as support for a huge number of other protocols, you're paying an awful lot for only slightly better performance.

In fact, in a real-world application, the performance benefit of Tornado is directly impacted by how good you are at dealing with asynchronicity.

[frognibble]

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.

[roder]

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

[wehriam]

What are you writing with twisted.web?

[roder]

Stay tuned :) !!!

[wehriam]

I will. Ping me if you get a moment.

[tr4nslator]

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.