Simultaneous connections

How to have +1,000 simultaneous clients connected to a single machine
running Rails?

Rails can not service more than ~40 simultaneous (open) connections on
the same box.

I don't think that's possible, say each mongrel process consumers 50MB
memory, then 20 mongrel process takes 1 GB. even if you have 16GB
memory, one box can serve at most 320 mongrel at same time.

1000 concurrent clients is very high traffic. you definitely need more
than one box to handle that much amount of traffic.


I'm supposed that it's because a process cann't have multiple threads.

yes, rails process is single threaded.


How to have +1,000 simultaneous clients connected to a single machine
running Rails?

Do you really have 1000 simultaneous clients? Or do you have 1000 requests per second? They are very different things...

Rails can not service more than ~40 simultaneous (open) connections on
the same box.

Add more servers... put behind a load balancer... until you can support the load you need.

I would guess that a 1,000 simultaenous clients is gonna be harder on your database than on your webserver though so keep that in mind as well.

I don't want to hijack the thread, but I think answers to my question
will be just as useful for the OP.

I'm relatively new to this game... can someone explain the ramifications
of this? When you say "simultaneous connections", what does that
mean... what is the lifespan of each? Is it open sessions we're talking
about? Or just the processing time of a page view?

I would define it as "number of active requests being served by rails" such that if I ran two mongrels I could have a maximum of *two* simultaneous connections.

However, two mongrels is enough to serve a lot of traffic if the requests don't take much time (ie. not uploading files, etc.)

For example... if a site gets 6000 hits an hour, from 1000 users each
checking in every 10 minutes, what does that mean in terms of mongrel

Depends on the site. Certainly don't need more than two. 6000 hits/hour is only 1.6 hits / second. That's not that much traffic at all. Assuming it's nicely spread out across the entire hour :slight_smile:

If you are truly looking at >1,000 simultaneous connections (and not simply
1,000 simultaneous *viewers*, only some of whom are making requests at any
given time), here's a list of things you can google for:

evented mongrel

That should get you started.

Actually, the mongrel isn’t locked during the upload. IIRC, mongrel streams the upload to a tempfile and only after the upload completes, it is handed over to Rails, that’s when the mongrel is locked. I believe the locking up happens AFTER the upload, when the mime boundaries of the uploaded file have to be parsed all over again. If you deal with lots of file uploads, you might want to consider running a merb server for the uploads, merb is multithreaded.

Best regards

Peter De Berdt

1000 open connections is much different than 1000req/sec. I host rails apps that have had up to 17,000 open connections at the load balancer and still serve traffick fine. 1000req/sec is another beast and is achievable, but if your expecting that many hits you are going to have to customize your application for performance.

  As long as you try to keep all of your actions as short as possible and push out anything that takes more then 1-2 seconds into an asyncronous work queue you can handle a surprising amount of traffick on 3-6 mongrels, I've seen 6 mongrels do a few million dynamic page views/day with a properly written app. But if you are really doing sustained bursts of 1000req/sec then you need to have a badass caching system in place and only generate dynamic content that you cannot cache.

  Also if you expect this much load you should gem install swiftiply and use the evented_mongrel, it's much more efficient and queueing requests.

-- Ezra Zygmuntowicz-- Founder & Ruby Hacker
-- Engine Yard, Serious Rails Hosting
-- (866) 518-YARD (9273)