Setup Question

I was trying to use httperf to do some benchmarking on my server and the
results were pretty dismal - very low connection /response rates and
lots of 5xx values. While there was some other stuff running on the
machine, its at least a dual core 2.6ghz with 6gb ram and it generally
never goes above 1-2% cpu usage so there is a lot of slack.

Its a (suse) LAMP machine with RoR running under a vhost. A coworker did
the initial setup, but I’m looking to tweak things as they are starting
to get a little slow for the users.

The command I use in a start up script
mongrel_rails start -d -e production -p 3000 -n 8 -c /wwwroot/path

I choose the n=8 from something I read over on
http://mongrel.rubyforge.org/index.html … can’t recall the exact page
but there was an estimate for 8-12 processors. Figured it couldn’t
hurt.

also read a little about running a mongrel cluster
http://mongrel.rubyforge.org/docs/mongrel_cluster.html
and didn’t know if this would help reduce some of the congestion.

The command I use in a start up script
mongrel_rails start -d -e production -p 3000 -n 8 -c /wwwroot/path

I choose the n=8 from something I read over on
http://mongrel.rubyforge.org/index.html … can’t recall the exact page
but there was an estimate for 8-12 processors. Figured it couldn’t
hurt.

Actually it can.

http://mongrel.rubyforge.org/docs/how_many_mongrels.html

We found that 4 was our sweet spot. 5 was too many.

-philip

Throwing httperf or ab at a single mongrel instance will give you an
idea what the theoretical average request/response rate should be per
server. And it would probably be just fine for a single user, right?
But a single mongrel may not be serving up enough requests to give
you the concurrency you need. In that case, you should load balance
to a mongrel cluster using pound or pen or mod_proxy_balancer. See if
firing up 3-5 mongrels and load balancing that way helps out.

If you are still in “setup” mode, then you may be doing some
premature optimization (I hate it when people say this to me :). You
might want to get a good grasp on your performance bottlenecks, and
then examine a combination of caching, serving static pages directly
from Apache, alternate “light stacks” like merb to speed things up.

Steve R. wrote:

Throwing httperf or ab at a single mongrel instance will give you an
idea what the theoretical average request/response rate should be per
server. And it would probably be just fine for a single user, right?
But a single mongrel may not be serving up enough requests to give
you the concurrency you need. In that case, you should load balance
to a mongrel cluster using pound or pen or mod_proxy_balancer. See if
firing up 3-5 mongrels and load balancing that way helps out.

Thanks for the tips. Yeah, the tuning page was the one where I got the
8 number from. I’ll be spending the morning playing around with the
benchmarks to see what number works best. Since there is a load
balancer, I’ll probably need to point at a single IP to do the testing
rather then the balanced IP.

Now, this is a little switch, but I was looking at the versions and my
install is about a year old. I had read somewhere that rails v1.2 was
actually slower then v1.1, but as the date on the article was a little
old that may be fixed now. Would there be any issues from upgrading any
of the following?

Mongrel 0.3.13.4 1.1.1
rails 1.1.4 1.2.5
ruby 1.8.4 1.8.6

And one other clarification if you could - Can I run multiple mongrel
processes without clustering? I’m interested in checking out the
clustering ability, but was wondering exactly what it buys you.