LOL. A couple hundred requests per second? Is that something to brag about?
What the fuck is the point of opening a million connections if it takes you 1.55 hours to process one request from each connection?
Ruby - Handling 1 Million Concurrent Connections
51–60 of 63 posts
Re: Ruby - Handling 1 Million Concurrent Connections
#52LOL. A couple hundred requests per second? Is that something to brag about? What the fuck is the point of opening a million connections if it takes you 1.55 hours to process one request from each connection?
mm, strange math.
179 means that while app holding and communicating to 1 million persistent connections it is still able to process 100+ standard requests per second. pretty enough to accept new clients to your online game, audio/video chat, podcast etc.
this graph shows how many requests per second app may process depending on amount of established persistent connections:
https://raw.github.com/slivu/1mc2/master/results/requests-pe...
Re: Ruby - Handling 1 Million Concurrent Connections
#53The 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…
> unfairly for the misconception that it [Ruby] is a slow language
Ruby is a slow language, certainly considerably slower than c/c++/c#/scala/java/etc. The question is whether the performance gap is big enough in your particular use case for it to matter.
Re: Ruby - Handling 1 Million Concurrent Connections
#54LOL. A couple hundred requests per second? Is that something to brag about? What the fuck is the point of opening a million connections if it takes you 1.55 hours to process one request from each connection?
mm, strange math. 179 means that while app holding and communicating to 1 million persistent connections it is still able to process 100+ standard requests per second. pretty enough to accept new clients to your online game, audio/video chat, podcast etc. this graph shows how many requests per second app may process depending on amount of established persistent connections: https://raw.github.com/slivu/1mc2/master/re…
I don't think your original post is very clear at all. I get the same number as the post you are criticizing: 1000000/179 / 60 / 60 = 1.55 hours.
Are there other messages being processed too? Which direction are the messages going? How big are they, what do they contain, how is the data processed. Also, if you have 1 million clients how do you handle all of them arriving at around the same time? How long did it take your system to get up to 1 million connections? Also how sure are you that each micro instance is sending and receiving the messages at exactly the expected rate and is not getting overloaded. What server type are you using for your central server?
Re: Ruby - Handling 1 Million Concurrent Connections
#55LOL. A couple hundred requests per second? Is that something to brag about? What the fuck is the point of opening a million connections if it takes you 1.55 hours to process one request from each connection?
mm, strange math. 179 means that while app holding and communicating to 1 million persistent connections it is still able to process 100+ standard requests per second. pretty enough to accept new clients to your online game, audio/video chat, podcast etc. this graph shows how many requests per second app may process depending on amount of established persistent connections: https://raw.github.com/slivu/1mc2/master/re…
"pretty enough to accept new clients to your online game, audio/video chat, podcast etc."
If 'pretty enough' means only allowing 179 new connections to your server per second, that's great. When you have a large event, everyone gets on your site at the same time, not to mention times like getting to work, lunch break, evening rush, etc. You ever hear of the slashdot effect? That's more than 200 requests per second.
Ignoring the poor connection time, you could only have 179 users actively using your app every second. Out of a million. %0.000179 of your user base. Talk about really shitty user engagement.
I'm not even going to talk about the incredibly bad idea it is to host a million connections using one server. The idea that "most websites" only do "about 100 requests per second" is laughable. Sure, the average may be 100, over a month, but that's nothing compared to peak times. Try tens of thousands per second. A high-traffic site might do something on the order of thousands of database writes per second. Which, when all those connections come in, will kill your database servers, which backs up your frontends, which is why you have to have fast forward-facing pre-loaded cache. But I digress.
Focus on scaling your application to actually handle traffic before you obsess over concurrent connections.
Re: Ruby - Handling 1 Million Concurrent Connections
#56Earlier 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.
> Pedantic, but important to note. Pedantic, but "pedantic" actually idiomatically means "not important to note".
In what culture?
In my dictionary it's "of or like a pedant"; a pedant being someone who is overly concerned with minor details.
Still... noted!
Re: Ruby - Handling 1 Million Concurrent Connections
#57Earlier quoted context omitted.
> Pedantic, but important to note. Pedantic, but "pedantic" actually idiomatically means "not important to note".
In what culture? In my dictionary it's "of or like a pedant" ; a pedant being someone who is overly concerned with minor details. Still... noted!
If the detail is minor, it's not important.
Re: Ruby - Handling 1 Million Concurrent Connections
#58very cool experiment
Re: Ruby - Handling 1 Million Concurrent Connections
#59Earlier quoted context omitted.
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
Depends whether looked at from the ops point of view or the end user point of view. You expressed concern about 1 million customers simultaneously having a bad experience. For a given end user if the hardware is equally reliable the odds of something happening are the same whether they are sharing with 1 million or 1 hundred thousand (or even have the server to themselves). On the ops side there is more to go wrong and failures will be more frequent but affect less end users each time.
The positive in the one big machine scenario is that you have potential to take strong efforts to keep it reliable. The advantage in the lots of machines scenario is that there is a better chance you have well tested failover solutions.
It is the combination of impact and risk that I am discussing.
Re: Ruby - Handling 1 Million Concurrent Connections
#60The author asserts that JRuby would consume more than 15GB of memory without providing any justification. Perhaps it would be better to actually try it rather than just making sweeping generalizations.