Ruby - Handling 1 Million Concurrent Connections

Post by e12e » Wed, Feb 20, 2013, 4:08 PM UTC

lucaspiller wrote: post #9

afhof wrote: post #6

I have to ask, is there even a practical purpose for this? Is there even some remote screwball application for having to have one machine handle 1,000,000 requests? One of the things I like about coming to HN is that the items on the front page are often actionable pieces of advice or clever and interesting hacks. I don't feel that "$LANG can do $LARGE_NUMBER of things" fits the bill. For example: C - Handling 1 Mill…

WhatsApp had over 2 million users connected to their (Erlang) server last year. http://blog.whatsapp.com/index.php/2012/01/1-million-is-so-2... Here is the same in Erlang for reference (from a few years ago, I would be interested to see if there is a more efficient way now): http://www.metabrew.com/article/a-million-user-comet-applica...

Post by FooBarWidget » Wed, Feb 20, 2013, 5:01 PM UTC

agentultra wrote: post #37

kenkam wrote: post #31

tl;dr OP throws 3 libs together, wrote a few scripts, made a few measurements. Look, it can handle 1 million connections. I like what he has done but don't know why it made HN frontpage. I'm guessing it's because it has Ruby, 1 million, and concurrent in the title. Not bashing the author, it's good work in its own right. I'm trying to understand how stuff like this makes frontpage HN. Where's the value of this articl…

I'm not a genius Ruby hacker by any stretch but if EventMachine is like any other "async IO framework" in other scripting languages then it is built on libev or libevent... so Ruby isn't really handling the connections, it's handling the callbacks. Pedantic, but important to note.

Post by [deleted] » Wed, Feb 20, 2013, 5:44 PM UTC

FooBarWidget wrote: post #43

agentultra wrote: post #37

Earlier quoted context omitted.

I'm not a genius Ruby hacker by any stretch but if EventMachine is like any other "async IO framework" in other scripting languages then it is built on libev or libevent... so Ruby isn't really handling the connections, it's handling the callbacks. Pedantic, but important to note.

EventMachine does not build upon libev or libevent. It implements all that stuff by itself.

Post by darkarmani » Wed, Feb 20, 2013, 6:16 PM UTC

kyledrake wrote: post #42

The practical purpose of this is to show that Ruby is perfectly capable of scaling to fit the needs of most companies. It kills the myth that Ruby is not capable of doing serious infrastructure work. That is EXACTLY THE POINT of this. We use Ruby for a ton of real work, and we are sick of seeing it get pummeled on unfairly for the misconception that it is a slow language and you are guaranteed to have scaling problem…

Post by hawleyal » Wed, Feb 20, 2013, 6:50 PM UTC

trailfox wrote: post #12

qompiler wrote: post #2

I have done this before using Java 7 async nio. The performance would drop like a brick when data received actually needed some sort of processing. How does this implementation hold up when you need to perform a O(n) operation on received data? Experiment with different sizes of n to see how the performance holds up.

Exactly. Establishing 1 million connections is pretty easy in any language that supports async io, even scripting languages. The article is super-vague about the direction of the traffic, the nature and size of the messages and how much of the application is actually written in Ruby (vs. just being a glorified wrapper around redis and other systems written in c/c++) and the amount of work actually being done by the a…