Erlang, Yaws, and the deadly Tornado

paul 16 years ago |

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

mononcqc 16 years ago | |

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

johnm 16 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)

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

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

tvon 16 years ago |

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

c00p3r 16 years ago |

epoll() matters.

jwecker 16 years ago | |

... to tornado.

superjared 16 years ago | | |

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

jwecker 16 years ago | | |

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.