Erlang, Yaws, and the deadly Tornado

http://lionet.livejournal.com/42016.html

by mindaugas • 17 years ago

61 14 17 years ago

lionet.livejournal.com

johnm• 17 years ago

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)

tvon• 17 years ago

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

al3x• 17 years ago

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.

davidw• 17 years ago

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.

wmf• 17 years ago

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

paul• 17 years ago

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

mononcqc• 17 years ago

This is answered in the comments: http://lionet.livejournal.com/42016.html?thread=774688#t7746...

superjared2• 17 years ago

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.

ellyagg• 17 years ago

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.

agazso• 17 years ago

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.

c00p3r• 17 years ago

epoll() matters.

jwecker2• 17 years ago

... to tornado.

superjared2• 17 years ago

Erlang uses epoll on Linux, kqueue on BSDs, et cetera.

Erlang, Yaws, and the deadly Tornado

Related Stories