Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ruby - Handling 1 Million Concurrent Connections

github.com

Post reply on HN
Print view View original

31–40 of 63 posts

Re: Ruby - Handling 1 Million Concurrent Connections

#31

Post by kenkam »

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 article? That Ruby can handle 1 mil connections? Am I missing something (even if it's obvious?)

I think someone mentioned better real world test cases. I agree that would be a place to start. Perhaps he could send more meaningful data to clients. Maybe market data for some stocks or something. '\0' is not very useful after all!

Re: Ruby - Handling 1 Million Concurrent Connections

#32

Post by 3amOpsGuy »

josephlord wrote: post #27
3amOpsGuy wrote: post #10

Earlier quoted context omitted.

What happens when one of the fully loaded 1 million connection nodes goes bang? That's potentially a million users getting a poor experience. Re-establishing a million connections at once is going to be hard on the network - the million were built up over a period of time previously yet now they're being re-established Big Bang style.

For any given user the probability of the one machine with everyone on it going bang is similar to the probability of the particular server that they were connected to in a horizontally scaled scenario. However the cost of redundancy may be higher if it is a replication of 100% of main system on the other hand a big system may be designed for high uptimes.

Would the probability not be less in this case? In general, less moving parts = less chance of outage. E.g. if a device is rated for 300,000 hours MTBF and you have 2 of them, their individual MTBF remains the same, but your chance of experiencing an outage in either one has doubled because you have 2 of them.

It's more the impact side of the risk equation i'm thinking of than the probability.

EDIT: typo

Re: Ruby - Handling 1 Million Concurrent Connections

#33

Post by mmahemoff »

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…

There's a lot of Ruby developers on HN and many of them are interested to know how it can scale.

Benchmarking experiments of this nature are actually remarkable because they are so rarely done. Most scaling and performance principles still arise from conjecture. It's not trivial to set up a test like this.

Also, _this_ is the place to start in preparation for a real world test. The next iteration, maybe a more realistic test, is only a fork away.

Re: Ruby - Handling 1 Million Concurrent Connections

#34

Post by willvarfar »

mixedbit wrote: post #23

I don't fully get the point of this benchmark. Connection handling is operating system business, so you should get similar numbers with any framework that runs on the same OS and correctly uses epoll (or an equivalent system call).

Tangent: back when I paid careful attention, all the epoll frameworks were level-triggered not edge-triggered.

Re: Ruby - Handling 1 Million Concurrent Connections

#37

Post by agentultra »

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.

Re: Ruby - Handling 1 Million Concurrent Connections

#38

Post by ksec »

slivuz wrote: post #20
moneypenny wrote: post #17

dumb question I thought the GC tunings, e.g. RUBY_HEAP_MIN_SLOTS, were only available in REE, rather than MRI?

starting with 1.9.3 they are also available on MRI, though not sure about 2.0.0 as there GC are highly refactored/optimized. > Starting with Ruby 1.9.3, the GC in mainstream ruby can also be tuned http://www.web-l.nl/posts/15-tuning-ruby-s-garbage-collector...

Would love to see the updated test once Ruby 2.0 is out in a few days time.

Re: Ruby - Handling 1 Million Concurrent Connections

#39

Post by moneypenny »

slivuz wrote: post #20
moneypenny wrote: post #17

dumb question I thought the GC tunings, e.g. RUBY_HEAP_MIN_SLOTS, were only available in REE, rather than MRI?

starting with 1.9.3 they are also available on MRI, though not sure about 2.0.0 as there GC are highly refactored/optimized. > Starting with Ruby 1.9.3, the GC in mainstream ruby can also be tuned http://www.web-l.nl/posts/15-tuning-ruby-s-garbage-collector...

Brilliant - thanks, hadn't found that info.

Re: Ruby - Handling 1 Million Concurrent Connections

#40

Post by kenkam »

mmahemoff wrote: post #33
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…

There's a lot of Ruby developers on HN and many of them are interested to know how it can scale. Benchmarking experiments of this nature are actually remarkable because they are so rarely done. Most scaling and performance principles still arise from conjecture. It's not trivial to set up a test like this. Also, _this_ is the place to start in preparation for a real world test. The next iteration, maybe a more realis…

Your forking argument won me over. Very good point.
Post reply on HN