[Mongrel] Mongrel Tuneup Guide: Questions

Vishnu Gopal g.vishnu at gmail.com
Tue Sep 5 07:25:32 EDT 2006


Since the list has been silent on this, I'll add some more of my
observations to this post.

I redid the test using my dev Mac mini as a guide. It's a dual core
machine, and here's what the results looked like:

The numbers again are the 10sec --nconns and the final --rate

1 Mongrel serving a test /test (w/o db access, very simple page):
1600 160

4 Mongrels serving a /test:
1400 190

1 Mongrel serving a full /index:
200 18

2 Mongrels serving a full /index:
190 26

Right, and so on (didn't bother to test this further)

The lesson learnt is that CPU loads become a factor very quickly with
mongrels and lots of hits on the server, esp if the CPU is paltry.

I'm not sure what kind of configuration all the rest of the tests I've
found on the net have been run on [aah here is one:
http://blog.kovyrin.net/2006/08/28/ruby-performance-results/ run on a
4x xeon with 4g ram :-)] but imho you still need a fast (much faster)
web server even on a single node to run rails/mongrel as compared to
php. Going the php way with very cheap machines is probably not going
to work.

The question I'm most interested in, and which I'd really like an
answer to is that I decided on Mongrel because of the HTTP stack used
throughout. I could basically have a load balancer hitting mongrels on
multiple machines... very flexible stuff and not possible with the
traditional fastcgi model.

If I do buy more (how many?) cheap machines serving 7req/s each, and
then load balance all of em (say with hardware), could I realistically
hope to hit comfy loads like 300 req/s? And will this continue to
scale?

Or should I just buy two 4x xeons and be done with it?

Again, a sample from my last 2mongrels/index logs:

Completed in 0.03958 (25 reqs/sec) | Rendering: 0.02801 (70%) | DB:
0.00585 (14%) | 200 OK

Vish


On 9/4/06, Vishnu Gopal <g.vishnu at gmail.com> wrote:
> Hi!
>
> I've been following the new mongrel tuneup guide (a huge thanks for
> that btw) and here are my results. I've basically only gotten to the
> point where I'm tuning up 1 mongrel because I suspect I have a
> performance problem with my rails app.
>
> http://mongrel.rubyforge.org/docs/how_many_mongrels.html
> The first number is the 10s nconns and the second is the max req/s as
> per the guide:
>
> Lighttpd serving static files:
> 6000 1800
> 1 Mongrel serving static files:
> 2800 200
> 1 Mongrel serving a bare /login page (without db query, no layout,
> just an action):
> 750 50
> 1 Mongrel serving my full /index page (many db queries, render with layout)
> 80 7
>
> Right, so I guess my  "rails measurement is horribly slow". The thing
> is, I've worked on the /index page a lot. I've implemented memcached,
> so db queries are basically minimal, and so the bottlneck basically is
> like this:
>
> The index page doesn't have any components, just 1 partial (called 2 times).
>
> logs (in debug mode) look like this (for /index):
> Completed in 0.21839 (4 reqs/sec) | Rendering: 0.16793 (76%) | DB: 0.02759 (12%)
>
> What do I do to optimize this situation? Think I'm missing something here...
>
> P.S. I'm running FreeBSD on a Celeron 2.0Ghz/2GB ram. And my processer
> is at 100% peak mostly when I'm hitting the load.
>
> Vish
>


More information about the Mongrel-users mailing list