People, please stop benchmarking with ab, it does not produce accurate results. All benchmarking of this sort should be done with Siege. It's easier to use too.
Would using Siege radically change the results?
Benchmarking Tornado vs. Twisted Web vs. Tornado on Twisted vs. Unicorn
11–20 of 27 posts
Re: Benchmarking Tornado vs. Twisted Web vs. Tornado on Twisted vs. Unicorn
#12People, please stop benchmarking with ab, it does not produce accurate results. All benchmarking of this sort should be done with Siege. It's easier to use too.
Would using Siege radically change the results?
Yep, I'd expect it to halve the requests per second for every test. Paul Jones (created the Solar framework) periodically releases some pretty authoritative benchmarks for the major PHP frameworks, and here's what he has to say on the topic:
Re: Benchmarking Tornado vs. Twisted Web vs. Tornado on Twisted vs. Unicorn
#13Earlier quoted context omitted.
Would using Siege radically change the results?
Yep, I'd expect it to halve the requests per second for every test. Paul Jones (created the Solar framework) periodically releases some pretty authoritative benchmarks for the major PHP frameworks, and here's what he has to say on the topic: http://paul-m-jones.com/?p=421
Good to know for future reference.
Re: Benchmarking Tornado vs. Twisted Web vs. Tornado on Twisted vs. Unicorn
#14Did not expect to see EM-httpserver kicking ass.
Re: Benchmarking Tornado vs. Twisted Web vs. Tornado on Twisted vs. Unicorn
#15Earlier quoted context omitted.
Would using Siege radically change the results?
Yep, I'd expect it to halve the requests per second for every test. Paul Jones (created the Solar framework) periodically releases some pretty authoritative benchmarks for the major PHP frameworks, and here's what he has to say on the topic: http://paul-m-jones.com/?p=421
His assertions are not confidence inspiring:
Re: Benchmarking Tornado vs. Twisted Web vs. Tornado on Twisted vs. Unicorn
#16Did not expect to see EM-httpserver kicking ass.
I think it's a c++ library (based on scanning the docs -- I could be wrong), so it's not too surprising to see it outperforming pure Python solutions.
Re: Benchmarking Tornado vs. Twisted Web vs. Tornado on Twisted vs. Unicorn
#17Did not expect to see EM-httpserver kicking ass.
I think it's a c++ library (based on scanning the docs -- I could be wrong), so it's not too surprising to see it outperforming pure Python solutions.
Indeed. http://github.com/eventmachine/eventmachine/raw/b4765960db91...
EventMachine consists of an extension library written in C++ (which can be
accessed from languages other than Ruby)
Re: Benchmarking Tornado vs. Twisted Web vs. Tornado on Twisted vs. Unicorn
#18Earlier quoted context omitted.
I think it's a c++ library (based on scanning the docs -- I could be wrong), so it's not too surprising to see it outperforming pure Python solutions.
Indeed. http://github.com/eventmachine/eventmachine/raw/b4765960db91... EventMachine consists of an extension library written in C++ (which can be accessed from languages other than Ruby) So the post compares pure Python web frameworks with a C++ library. And not even a good library based on Boost/Asio or libevent.
Is eventmachine's c++ lib really not a "good library"? If not, why?
Re: Benchmarking Tornado vs. Twisted Web vs. Tornado on Twisted vs. Unicorn
#19It would also be fun to see how the raw Tornado httpserver (http://github.com/facebook/tornado/blob/master/tornado/https...) performs without the Tornado web.py framework on top of it.
Re: Benchmarking Tornado vs. Twisted Web vs. Tornado on Twisted vs. Unicorn
#20Earlier quoted context omitted.
Indeed. http://github.com/eventmachine/eventmachine/raw/b4765960db91... EventMachine consists of an extension library written in C++ (which can be accessed from languages other than Ruby) So the post compares pure Python web frameworks with a C++ library. And not even a good library based on Boost/Asio or libevent.
Is eventmachine's c++ lib really not a "good library"? If not, why?
It reinvents the wheel. As a developer, you have to have really good reasons not to use it. Especially since Boost license is practically AS-IS, they could have taken the original source.
It is possible they are better at this problem than others, but that is very unlikely, from experience. As a developer it isn't wise to do a reliability test on a new library by yourself.
Making a portable async framework is quite error-prone because of the heterogenous situations it could face. You can witness this reading libevent's evolution over the years. And those developers are as good unix coders as you can possibly get with vast experience on the subject (since mid 90s.) I bet the Boost/Asio guys are very good C++ coders too, Boost is as close as you can get to STL.
At a glance, http://rubyeventmachine.com/ doesn't state why a new C++ async library. They only mention the Reactor Pattern, and Boost/Asio supports it:
http://www.boost.org/doc/libs/1_40_0/doc/html/boost_asio/ove...