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

11–20 of 63 posts

Re: Ruby - Handling 1 Million Concurrent Connections

#11

Post by Erwin »

adlpz wrote: post #5
tmartiro wrote: post #3

Good job... You can also open 1 million connections using one linux box a) increase local port range 1024 to 65535 b) setup 17 ip address. c) open from each ip address 58824 connections

What would be the point of that? The bottleneck here is not the amount of ports. TCP can handle concurrency over one single input port just fine. The issue here is concurrency on the service software. If you have to launch a million instances to listen on a million different ports, you are doing it wrong.

An TCP connection is uniquely identified by a {local IP, remote IP, local port, remote port} tuple.

So if you are on 192.168.1.1 and want to connect to a specific port on 192.168.1.2 there aren't enough free port numbers to get 1 million connections. Thus the extending of the "ephemeral port range" (the local port number the kernel is allowed to assign) and addition of more local IPs.

Re: Ruby - Handling 1 Million Concurrent Connections

#12

Post by trailfox »

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 app. 179 requests per second is hardly something to brag about while you've completely saturated 8 cpu cores.

Re: Ruby - Handling 1 Million Concurrent Connections

#13

Post by [deleted] »

Erwin wrote: post #11
adlpz wrote: post #5

Earlier quoted context omitted.

What would be the point of that? The bottleneck here is not the amount of ports. TCP can handle concurrency over one single input port just fine. The issue here is concurrency on the service software. If you have to launch a million instances to listen on a million different ports, you are doing it wrong.

An TCP connection is uniquely identified by a {local IP, remote IP, local port, remote port} tuple. So if you are on 192.168.1.1 and want to connect to a specific port on 192.168.1.2 there aren't enough free port numbers to get 1 million connections. Thus the extending of the "ephemeral port range" (the local port number the kernel is allowed to assign) and addition of more local IPs.

[deleted]

Re: Ruby - Handling 1 Million Concurrent Connections

#14

Post by gilgoomesh »

Erwin wrote: post #11
adlpz wrote: post #5

Earlier quoted context omitted.

What would be the point of that? The bottleneck here is not the amount of ports. TCP can handle concurrency over one single input port just fine. The issue here is concurrency on the service software. If you have to launch a million instances to listen on a million different ports, you are doing it wrong.

An TCP connection is uniquely identified by a {local IP, remote IP, local port, remote port} tuple. So if you are on 192.168.1.1 and want to connect to a specific port on 192.168.1.2 there aren't enough free port numbers to get 1 million connections. Thus the extending of the "ephemeral port range" (the local port number the kernel is allowed to assign) and addition of more local IPs.

Except there's no assumption here that the 1 million connections are between just two computers. Clients are spread over 50 different EC2 instances (which each have a unique address). The host does not need more ports in this scenario and the clients are using 20,000 ports (possible without altering port allocation).

Re: Ruby - Handling 1 Million Concurrent Connections

#16

Post by dschiptsov »

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.

The performance would drop like a brick when data received actually needed some sort of processing - priceless!

This reminds me another post from a guy who measured and graphed JVM performance in adding (or multiplying, can't remember) numbers. And he concluded, that, well, JVM is fast at doing dumb arithmetic in a loop.)

Re: Ruby - Handling 1 Million Concurrent Connections

#20

Post by slivuz »

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

Post reply on HN