I would really like to see Twisted vs Tornado Documentation. The performances are close enough that I don't think it should be a deciding factor in which of these to use. Albeit performace is always an important metric that should be watched to keep things from getting worse.
Twisted.web vs Tornado Performance, part deux
31–38 of 38 posts
Re: Twisted.web vs Tornado Performance, part deux
#32I would really like to see Twisted vs Tornado Documentation. The performances are close enough that I don't think it should be a deciding factor in which of these to use. Albeit performace is always an important metric that should be watched to keep things from getting worse.
In fact, all those comparisons compare two totally different frameworks. One is for the internet (which really includes far more then http) and one is for the web (which mostsly includes http).
Re: Twisted.web vs Tornado Performance, part deux
#33Innocently 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…
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
Great article, thankyou!
Re: Twisted.web vs Tornado Performance, part deux
#34Innocently 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.
Thanks, I'll give it a go with lighttpd too.
Re: Twisted.web vs Tornado Performance, part deux
#35These tests are completely useless, since most of the measurements are done at a point where response time has already degraded unacceptably. I don't need a web server that performs slightly better when massively overloaded.
The sweet spot to measure is between a response time of 0s to 1s. After that, you need to be looking at getting more servers, anyways.
A better benchmark would start by swapping the axes of the graph and asking the question: "how many users can I support while keeping response time acceptably low?"
Re: Twisted.web vs Tornado Performance, part deux
#36Re: Twisted.web vs Tornado Performance, part deux
#37Summary: * 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
Executive summary:
Ignore this "benchmark", the author simply doesn't have a remote clue what he is doing.
500ms Mean Response Time at 100 concurrent requests, are you kidding? Did you run the "benchmark" over a 56k modem?
For the record, one would expect sub-100ms response times under that load, even on modest hardware.
Re: Twisted.web vs Tornado Performance, part deux
#38Summary: * 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
Executive summary: Ignore this "benchmark", the author simply doesn't have a remote clue what he is doing. 500ms Mean Response Time at 100 concurrent requests, are you kidding? Did you run the "benchmark" over a 56k modem? For the record, one would expect sub-100ms response times under that load, even on modest hardware.
wow...
The test was run on two VMs on the Rackspace cloud using the public IP addresses.