Deployment questions

Rails
1

All,

I have some basic deployment questions:

  1. How many concurrent requests can be served, on average, by one
    Mongrel process (I know, it depends)? Just a rough idea.

  2. I thought I read something about ~40MB of memory/request used on the
    server on average - is this correct? That seems really high to me.

Thanks,
Wes

2

Wes:

Run your owntests. It’s the only way you’re going to get good results.
Can
be as low as 3, can be as high as 100+. Use httperf and test, test,
test.

I’ve posted some test strategies on this form a few times… maybe do a
search for httperf and you might see something I wrote a few weeks ago.

I’d recommend running more than one Mongrel unless you can delegate most
of
your requests to a static server using caching. Browsers need to grab
your
css files and js files, and if you’re not offloading that to Apache then
one
instance is really going to choke.

3

Hi~

On Jan 23, 2007, at 9:30 AM, Wes G. wrote:

All,

I have some basic deployment questions:

  1. How many concurrent requests can be served, on average, by one
    Mongrel process (I know, it depends)? Just a rough idea.

mongrel and any other way of running rails can only serve 1
concurrent request at a time. ActionPack is not threadsafe so there
is a big mutex lock around each dispatch to rails.

This means you really need at least 2 mongrels for a production app.
If you only had one and for example a user uploads a large file, no
other requests will get served until the upload finishes.

So you have to run a cluster of mongrels to get around this. 2 or 3
mongrels behind nginx or apache can serve quite a bit of traffic and
users. But it varies depending on the type of app.

  1. I thought I read something about ~40MB of memory/request used on
    the
    server on average - is this correct? That seems really high to me.

Mongrel uses a bit less memory on 32 bit systems but on 64bit systems
a rails app running on 1.2.1 will take on average 40-75Mb of ram per
mongrel, and you need 2 or 3 mongrels per app.

Rails is memory hungry it’s just a fact of life for a rails dev. It’s
way cheaper to create great software with rails but it will require
more ram and hardware to deploy your app. So it’s a tradeoff of
developer time and hosting costs.

Thanks,
Wes

Cheers-
– Ezra Z.
– Lead Rails Evangelist
– [email protected]
– Engine Y., Serious Rails Hosting
– (866) 518-YARD (9273)

4

Ezra Z. wrote:

mongrel and any other way of running rails can only serve 1
concurrent request at a time. ActionPack is not threadsafe so there
is a big mutex lock around each dispatch to rails.

Ezra,

Thanks for the response. This raises a couple of questions for me.

  1. I thought that I had heard that ActionPack is not thread safe.
    Is this because there is common class-level code being executed for each
    request? Is it difficult to make it thread safe? What would be
    involved?

  2. Is it a true statement that Rails can only support as many (truly)
    concurrent requests as Mongrel instances?

Thanks,
Wes

5

way cheaper to create great software with rails but it will require
more ram and hardware to deploy your app. So it’s a tradeoff of
developer time and hosting costs.

Another option is litespeed (or any server that can spawn/kill the rails
instances on demand). I recently switched from apache/mongrel to
litespeed for exactly this reason. I have several small sites (by
small,
I mean I’m pretty much the only one who cares). Running 6-8 mongrels
simply wasn’t going to happen on my little box. But with litespeed I
can
tell it not to run any lsapi instances, then spawn a max of 5 for each
app, then kill them off if they’ve been idle for more than a couple of
minutes.

This way I get the best of both worlds in my physically limited server.

Anyway, just another option…

6
  1. Is it a true statement that Rails can only support as many (truly)
    concurrent requests as Mongrel instances?

Yes, but remember that mongrel can serve a lot of rails requests per
second (depending on the app)… We run 4 mongrels at work, but serve
quite
a bit of traffic with that…

-philip

7

On Jan 23, 2007, at 12:30 PM, Wes G. wrote:

  1. I thought that I had heard that ActionPack is not thread safe.
    Is this because there is common class-level code being executed for
    each
    request? Is it difficult to make it thread safe? What would be
    involved?

There are a number of things that make AP not thread safe. Part of
that is because thats the way it has been from the begining mostly,
and so code is added without thought to thread safety. This is a
viable approach that has allowed rails to do so much of the magick
that it is known for, but it sacrifices multi threaded performance to
do so.

I have experimented with a mongrel rails dispatcher that doesn’t lock
around route recognition and mime parsing but only locks when your
controllers action is being run. But this fails miserably when hit
with concurrent requests. I suspect it is a large job to make AP
thread safe and the boat has kinda sailed on it. If someone really
wanted to make AP thread safe they coudl start by writing failing
test cases that show where it falls down in a threaded env. But there
is a lot of code to audit in AP to make this happen.

  1. Is it a true statement that Rails can only support as many (truly)
    concurrent requests as Mongrel instances?

Yes this is true. But in practice you will almost never get requests
at exactly the same time. So if you keep your rails actions fast then
3 mongrels can serve quite a bit of concurrency with httperf before
it falls down.

Thanks,
Wes

Cheers-

– Ezra Z.
– Lead Rails Evangelist
– [email protected]
– Engine Y., Serious Rails Hosting
– (866) 518-YARD (9273)

8

Thanks for the post, Ezra. That helps. Now I see that optimizing your
Rails app. is even more important that it always was, if that makes
sense :).

I just finished reading that length post on the Ruby forum where you, a
guy named Sunny, and Ed Borasky hashed out performance issues in
Ruby/Rails. It was incredibly informative (see:
Two Advanced Ruby Performance Questions - Ruby - Ruby-Forum).

Are you still working on Merb?

Wes

9

On Jan 23, 2007, at 2:03 PM, Wes G. wrote:

Two Advanced Ruby Performance Questions - Ruby - Ruby-Forum).

Are you still working on Merb?

Wes

Yeah I am still working on merb. It is coming along nicely. It is
running over 20 production apps now. I still use ActiveRecord but I
pretty much wrote my own implementation of actionpack that is a lot
more thread safe then AP. I still have a mutex lock but it only locks
while a controller action is being run. All the route recognition and
mime parsing happens in a thread safe way so that merb can handle
many concurrent connections with one instance.

For example, a fresh rails app with one controller that just does
render :text => “hello!” so that it invokes the full rails stack.
Right now that benchmarks on my macbookpro at 120 req/sec on one
mongrel, it also cannot handle it when you set the httperf
concurrency setting to more then 1. Doing the same thing in merb
clocks in at about 350-400 req/sec and can handle up to 100 or so
concurrent connections before it starts to slow down. Merb also only
uses 20Mb of ram per instance so you can run 2 or 3 of them in the
same ram that you can run one mongrel with rails loaded.

Anyway merb is great for smaller projects or for rewriting critical
sections of your rails app in something faster. But merb is nowhere
near as cushy as rails with regard to features. Merb is definitely
heavily inspired by rails. I took a great many idioms from rails. But
I left out some stuff I feel is bloat and cruft in favor of being
closer to pure ruby and letting you build the framework to suit your
needs instead of just getting the kitchen sink and whatever baggage
comes with that.

http://merb.devjavu.com/

Cheers-
– Ezra Z.
– Lead Rails Evangelist
– [email protected]
– Engine Y., Serious Rails Hosting
– (866) 518-YARD (9273)