Erlang, Yaws, and the deadly Tornado

The Tornado part of the test is mostly useless (and misleading) since he's running it with select instead of epoll.

So much better than so much of the discussion around Tornado, that's for sure.<p>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.

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.<p>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.

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.<p><a href="http://www.usenix.org/events/nsdi06/tech/full_papers/schroeder/schroeder_html/index.html" rel="nofollow">http://www.usenix.org/events/nsdi06/tech/full_papers/schroed...</a>

Performance aside, the release of Tornado has been very good for the non-blocking httpd world.

epoll() matters.