Topic: Raising requests / sec

I can't seem to get more than about 8 requests / sec out of Mongrel, which seems really low for a app running in production mode using page caching (which doesn't really seem to make a difference).  In the peepcode episode, topfunky is getting hundreds of requests per sec!

I'm testing on a local network with httperf on one machine with my app on another.  Running httperf with 1000 connections yields 22 samples and takes like 3 minutes to complete.

Can anyone help me to diagnose out why this is so low?

(I have verified that I am running in production and that the cache file is being generated).

Re: Raising requests / sec

This is 8 req/s as measured by httperf? Is this performance common to all pages or just some. What happens if you create a do-nothing controller with a do-nothing index action that simply does:

render :text => 'hello, httperf!'

It seems to me you are trying to get too many connections through a single mongrel. Remember, Rails throws a mutex lock on the owning process at the start of each request and releases it at the end. That means concurrency is roughly equivalent to the number of mongrels running.

I just ran ab on my localhost mongrel and the results are:

Requests per second:    219.82 [#/sec] (mean)

[httperf benchmarks this around the same]

The page being served hits the database for a has_many :through join and spits up a form based on some choices. Obviously, because of AR caching, the number is artificially high because the same query is issued over and over; however, it suggests that you should be able to serve better than 8 r/s of cached pages in a production environment.

If you really mean to serve 1000 concurrent requests, you should look into fair balancers like Haproxy (http://haproxy.1wt.eu/) and allocating enough mongrels to serve your predicted load without bringing the machine to its knees.

Re: Raising requests / sec

Remember that hardware can yield a lot difference in the results.

Moreover topfunky must have been using page caching so that's why you have so many requests per second.

I tested on a PIII server, and I can get 30req/s with no caching and sessions stored in AR.

Re: Raising requests / sec

You might need to tune the number of connections. Issues with concurrency are why we need to run multiple mongrels to increaase throughput beyond a certain point.

I get 40-50 req/sec from a 256Mb Slice with 2 Mongrel instances behind Apache   and views driven by multiple ActiveRecord models.

Toby Hede
===================================================
FiniteStateMachine - Software Development for Social Networks
===================================================

Re: Raising requests / sec

What's the equivalent cpu of your slice?

Re: Raising requests / sec

Um, whatever the 256MB Slice gives you ...
http://www.slicehost.com/

Toby Hede
===================================================
FiniteStateMachine - Software Development for Social Networks
===================================================

Re: Raising requests / sec

My terminology might've been a little off - I meant the reply rate, which is supposedly the main thing you're supposed to be looking at.

I'm getting an average of 8 per second on my slice in production mode, no caching.  But as above, I was testing on an old box of mine on my home network, without apache in front and WITH page caching and was only getting 8, which was really weird since topfunky was getting hundreds per second.  Perhaps it is hardware.

Re: Raising requests / sec

Any improvements?

But I guess that your slice is super slow and therefore you get the crapy performance. Even my PIII 500 beats the hell out of your slice :-P

That's the problem with slices hosts, you don't really know what's your cpu power...