21–27 of 27 posts
Earlier quoted context omitted.
3-4x the number of simultaneous connections (ignoring the actual performance gains) strikes me as pretty significant, even under a limited test.
The test is not just limited, it's completely meaningless because the portion of the stack he tested is not going to be your bottleneck in any real application. When will people learn that 'ab' is not a suitable benchmark for application servers...
Earlier 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.
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.
The benchmark eventually resumes 10-30 seconds later. It seems OS X can't free up closed ports fast enough.
I've tried this with numerous HTTP servers (including Apache) and both ApacheBench and Siege, so it seems like it's an OS problem.
Earlier 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.
55% of EventMachine's codebase is written in Ruby. Some parts of Tornado is written in C.