Estimating requests / sec.

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

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.

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 ;

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.

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.

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.