The fair proxy balancer

[Alexander Staubo]

On 12/3/07, Grzegorz Nosek <grzegorz.nosek at gmail.com> wrote:
> The standard question -- have you tried the latest snapshot? :) (though
> it might not be any different, asking just in case). Also, as you mention 5
> 10 second requests, please increase:

I was using an older snapshot (there was no new snapshot at the time I
wrote my comment, I'm pretty sure).

The new version, in combination with FS_TIME_SCALE_OFFSET set to 60000
for good measure, seems to cause a more uniform the distribution. So
that's a lot of help. Thanks!

Even so, sometimes the balancer seems to go into a state where it's
not using all mongrels:

1003     23335 66.0  8.6 384908 360700 ?       Rl   10:31  29:28
mongrel_rails [10010/433/358]: handling 127.0.0.1: HEAD
/feed/calendar/global/91/6de4
1003     29040 28.3  5.7 257764 238764 ?       Rl   Dec04 278:29
mongrel_rails [10011/18/3465]: handling 127.0.0.1: HEAD
/feed/calendar/circle/2289/9441
1003     18917  4.3  7.9 350384 330632 ?       Sl   Dec04  87:32
mongrel_rails [10012/0/1707]: idle
1003     19334  7.5  4.6 211640 192568 ?       Sl   Dec04 152:54
mongrel_rails [10013/0/3666]: idle

The first mongrel, as you can see, has 433 requests queued. This is
something that happened during the night.

Some of these requests time out; some of these requests are very
expensive legacy feeds that have never been optimized. Does the
balancer penalize upstreams that time out a lot, by any chance? Is
there a way to force the algorithm not using any weighting, but always
schedule connections to the upstream with the fewest queued requests?

> If increasing FS_TIME_SCALE_OFFSET does not help, could you please
> compile nginx --with-debug and gather the debug_http data?

I will do this.

Alexander.