Erlang, Yaws, and the deadly Tornado(lionet.livejournal.com)
lionet.livejournal.com
Erlang, Yaws, and the deadly Tornado
http://lionet.livejournal.com/42016.html
16 comments
The Tornado part of the test is mostly useless (and misleading) since he's running it with select instead of epoll.
This is answered in the comments: http://lionet.livejournal.com/42016.html?thread=774688#t7746...
So much better than so much of the discussion around Tornado, that's for sure.
Definitely would like to see two more takes: * long-poll setup (lots of idle connections with sporadic bursty activity) * thundering herd (max sustainable active connections)
Definitely would like to see two more takes: * long-poll setup (lots of idle connections with sporadic bursty activity) * thundering herd (max sustainable active connections)
I love Erlang--don't get me wrong--but this is flawed. He uses Tornado on a system that doesn't have epoll() so it uses select() instead, and then the author continues to show how Tornado will fail at higher concurrency levels. This is not a problem with Tornado but with select. I imagine that Erlang will still generally rout Tornado when using epoll, just not as significantly.
Tornado failing at high levels was a secondary point. The main point was the performance. I have serious doubts as to whether epoll would make a significant difference there, but I'd love to see someone making the claim prove it.
In fact epoll was created specifically because select does not scale well. That is, if you have lots of open connections, and an event happens on one of them you have to iterate all the file descriptors to see which one was active.
With epoll, only those descriptors are returned which were active. With 8000/s (as in the tests) this really makes a significant difference.
With epoll, only those descriptors are returned which were active. With 8000/s (as in the tests) this really makes a significant difference.
Neat technologies at play here, but at the end of the day, it's all kind of moot. It doesn't matter how many toy HTTP requests per second your web server can do: once you hook it up to a database, a network-based caching layer, or any other RPC mechanism, that's your new bottleneck.
It's nice to have a fast web server, and I'd choose a fast one over a slow one, but it would be nice if these sort of benchmarks included database access or some other real-world web application property in each request/response loop.
It's nice to have a fast web server, and I'd choose a fast one over a slow one, but it would be nice if these sort of benchmarks included database access or some other real-world web application property in each request/response loop.
Sure, fair point. However, something that is really important about Erlang is that you don't have to do anything special in your request handler, even if you are doing long-running calculations. Since it has its own scheduler, you just write your code, and the runtime takes care of giving it time slices as needs be.
Of course, this doesn't solve the DB issue, but it's still noteworthy.
Of course, this doesn't solve the DB issue, but it's still noteworthy.
I don't care about the ongoing Tornado vs. the world discussion, but there's something to learn about benchmarking here. These benchmarks use a more realistic open system model so that you can see the effect of overload, which most benchmarks ignore.
http://www.usenix.org/events/nsdi06/tech/full_papers/schroed...
http://www.usenix.org/events/nsdi06/tech/full_papers/schroed...
Performance aside, the release of Tornado has been very good for the non-blocking httpd world.
[deleted]
[deleted]
epoll() matters.
... to tornado.
Erlang uses epoll on Linux, kqueue on BSDs, et cetera.
Understood. There just seem to be a lot of complaints that the system he used for benchmarking didn't have epoll and that Tornado was slow because of select. I agree. But Erlang on that machine obviously didn't use epoll either.