
Erlang, Yaws, and the deadly Tornado - mindaugas
http://lionet.livejournal.com/42016.html
======
paul
The Tornado part of the test is mostly useless (and misleading) since he's
running it with select instead of epoll.

~~~
mononcqc
This is answered in the comments:
[http://lionet.livejournal.com/42016.html?thread=774688#t7746...](http://lionet.livejournal.com/42016.html?thread=774688#t774688)

------
johnm
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
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
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
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
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
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
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/schroeder/schroeder_html/index.html)

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

------
c00p3r
epoll() matters.

~~~
jwecker
... to tornado.

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

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

