Estimating requests / sec.

rubyonrails-talk
1

Hi;

We're using Rails to serve dynamic data for a bunch of ads, which are going to be exposed about 3 million times/day.

To estimate the hardware setup, we're trying to figure out what our peak load will be. They'll be running on your average news/entertainment sites, anyone know of a somewhat good formula to guesstimate what our likely scenario is going to be?

Our best guess is that three peak hours (lunch+evening) will consume half of all queries. This would leave us with peaks at about 150 req./s. Sound good?

Also, I've been told/read that 40 req./s. is what to calculate for each Mongrel for a simple Rails app, does that seem reasonable?

Many thanks, Gustav

2

Gu stav wrote:

Hi;

We're using Rails to serve dynamic data for a bunch of ads, which are going to be exposed about 3 million times/day.

To estimate the hardware setup, we're trying to figure out what our peak load will be. They'll be running on your average news/entertainment sites, anyone know of a somewhat good formula to guesstimate what our likely scenario is going to be?

Our best guess is that three peak hours (lunch+evening) will consume half of all queries. This would leave us with peaks at about 150 req./s. Sound good?

Also, I've been told/read that 40 req./s. is what to calculate for each Mongrel for a simple Rails app, does that seem reasonable?

Many thanks, Gustav

There are a lot of factors, like the hardware, other processes that are running, your architecture, etc. Your best bet may be to start relatively slow -- like one client site -- and see what your peaks are, where your bottlenecks are, iterate, and scale up as you go. You should pretty quickly be able to calculate your throughput and mongrel requirements.

3

Gu stav wrote:

We're using Rails to serve dynamic data for a bunch of ads, which are going to be exposed about 3 million times/day.

To estimate the hardware setup, we're trying to figure out what our peak load will be. They'll be running on your average news/entertainment sites, anyone know of a somewhat good formula to guesstimate what our likely scenario is going to be?

There are a lot of factors, like the hardware, other processes that are running, your architecture, etc. Your best bet may be to start relatively slow -- like one client site -- and see what your peaks are, where your bottlenecks are, iterate, and scale up as you go. You should pretty quickly be able to calculate your throughput and mongrel requirements.

Problem is that we can't learn as we go, we get the full amount of traffic as soon as the ad hits the media channels, hence the need for some well educated guessing ;

4

In our experience, that *number* would be about right, statistically, for several hundred running applications.

Some are less than 1 req/sec and others push beyond 80 req/sec.

However, those numbers are per *core*, not per Mongrel, and do not include DB server cores.

5

As noted in the original post, not all requests are created equal, so anything that can be intercepted and served statically can be turned around in a fraction of the time it takes to render a dynamic page. Even if it's just assets that are served from an asset server, you're way ahead of the game with that strategy. Caching infrequently used pages or fragments is a bonus if the application is shaped right for that.

6

Here's a simple formula to follow.   A. Take the (average or median) request time, in seconds. Say, 0.250 seconds (250ms)   B. How many requests do you want to handle at peak? (e.g. 10,000 a minute, 166 a second)   C. Multiply A x B : 0.250 * 166 = 41.5

    So you need about 40 mongrels to handle the load. At about 60MB per listener, that's 2.4GB of RAM, plus a bit of room for leakiness and swapping. Ezra at Engine Yard suggest "about 10 dogs per CPU core", which means that if we have a 4-core opteron box with 3GB of RAM, then this is possible on one box.     Your mileage will vary, which means, if the box is lagging, remove a few mongrels.