Twisted.web vs Tornado Performance, part deux

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 Twisted and Tornado, wouldn't we see this seriously degrade when the server had to anything more than 'hello world'? My worry is having a Twisted/Tornado app and only using 1/4th of my availble processing power: am I wrong to do so?

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

That applies to threading.

Twisted and Tornado are epoll/kqueue/etc-based and do not use threads.

Here's a good article on the differences between strategies: http://www.kegel.com/c10k.html

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.

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 not in the software under test but with the VM, or alternatively, with other software running on the host the VM is running on.

That makes it very difficult to assign meaning to all this.

If you test software you do it in an environment that controls all the variables as much as possible otherwise the results will not help you in making decisions.

If people run software 'in the cloud' then that's a different story altogether, then you test the same software side-by-side on your bare machine vs your 'in the cloud' setup and you benchmark those.

This test is labelled 'twister vs tornado', not 'twister in the cloud' vs 'tornado in the cloud'.