I am excited about ec2-fleet tool. How expensive is the tests in your case?
a micro instance costs 2 cents per hour, so $1 per hour for 50 instances.
Ruby - Handling 1 Million Concurrent Connections
21–30 of 63 posts
Re: Ruby - Handling 1 Million Concurrent Connections
#22Let's make a bit like a real world.) The test case could be like this:
A lookup. Get any reasonable big publicly available simple data-set and import it into any persistent storage (a sorted file is OK) and let a client perform a lookup for a row (preferably utf8 text ,)) then render a simple html table in response. As stupid as MVC.
or
Perform any simple lookup, but only for authenticated user (against some passwd-like file, to make it easy).
Then we could see how cool any JVM stuff or over-engineered OO ruby frameworks really are, with all that shinny graphs and smooth curves.
Re: Ruby - Handling 1 Million Concurrent Connections
#23I 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).
Re: Ruby - Handling 1 Million Concurrent Connections
#24Earlier quoted context omitted.
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).
This was a reply to tmartiro's thread, where he says "You can also open 1 million connections using one linux box" and describes how you could do it a single instance rather than 50 separate ones; adlpz asked "what would be the point of that".
Re: Ruby - Handling 1 Million Concurrent Connections
#25and as usual "handling" means nothing.
New headline: Ruby responds to TCP stack. Awesome. Go home ruby newbs. Your a bunch of fucking idiots
Re: Ruby - Handling 1 Million Concurrent Connections
#26Earlier 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.
Well, of course, you can only have 65535 established connections sending data concurrently at a given point in time. But what I meant is, that is not the bottleneck at all, but the software behind handling all these requests, so tmartiro's comment was either pointless or sarcastic.
Note: This scenario is only valid for two computers talking to each other. As gilgoomesh said, if you have multiple clients you have virtually unlimited valid connection tuples (src addr, dst addr, src prt, dst prt).
Re: Ruby - Handling 1 Million Concurrent Connections
#27I 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…
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.
Re: Ruby - Handling 1 Million Concurrent Connections
#28Re: Ruby - Handling 1 Million Concurrent Connections
#29"JRuby would for sure consume much more than 15GB of RAM"
I wouldn't say this with such certainty, at least without any empirical evidence. I'll try a JRuby BM when I get home...