Hi,

I've made a strange observation, and am unsure if the result is because 
of an unrealistic setup, or if there might be a problem in pound.

For curiosity, I tested pound with two very different speeded (but both 
rather slow) backends. With ab, one would give something like 5 
pages/second, the other only 0.3 pages/sec. The numbers were almost 
identical no matter if ab was run locally or remote, or if I connected 
the respective backend directly or through pound with only one backend 
configured.

Now, what performance would one expect if both backends were balanced by 
pound? For me, with both backends configured to be the same prio I 
thought at best it would come to 5.3 pages/sec., at worst to 5/sec. But 
in fact the overall performance went down to something more like 
between 1 or 2 pages/sec. The situation gets a little bit better if the 
slower backend gets a prio of 1 and the faster a prio of 9, but it's 
still not better than between 3 or 4 pages/sec.

Now I'm wondering, is this how it should be?

Testing was with 1.7, because I couldn't make current running 
(immediately times out on the slow host, see 
http://www.apsis.ch/pound/pound_list/archive/2004/2004-05/1083776972000#1083776972000).


Thanks for listening,

Sascha
[...]

On Tuesday 11 May 2004 15.17, Sascha Ottolski wrote:[...]

Yes, it is. You are responsible for setting the correct parameters for the 
servers.

To use your example: one server does 5 reqs/sec, the other 0.3 reqs/sec, or if 
you prefer 0.2 secs/req and 3.3 secs/req (note the 1-to-16.5 disparity). If 
you set priorities as 1 and 1 about half the requests go to the first server, 
and half to the other. Average response time: 1.75 secs/req. Changing 
priorities to 9 and 1 makes average response time 0.51 secs/req. In practice 
the times will be a bit better because as the faster server completes 
requests new ones come in (Poisson vs. uniform distribution).

Moral of the story: don't use two servers that are that different, or use many 
more than two.
[...]

Sorry for missing that one. Try latest -current (there is a new one today), 
check networking setup. 1.7 has a major problem if you have more than one 
listener.[...]

Am Dienstag, 11. Mai 2004 15:55 schrieb Robert Segall:[...]

Hi Robert,

thanks for the explanation. However, I'm still wondering if this is 
really what one would expect. Of course, it doesn' make too much sense 
to have backends with such different performances, but it still isn't 
unrealistic. For example, what if a backend is overloaded for whatever 
reason, and becomes very slow in responding. I think, such a situation 
should not result in taking the whole cluster down to a speed below of 
what a single backend thats still is available to handle (the other 
backends might be idle).

So far for my dreams :-). Unfortunately, I have no idea how complex it 
would be to implement a scheduler that would recongnise if servers are 
idle and adjust the forwarding of requests accordingly. A simple 
approach might be, that pound knows which backends have requests 
pending, and which not, thus sending the next request to a server that 
has none (or the server which has the shortest queue of pending 
requests).


Thanks,

Sascha
[...]

On Friday 14 May 2004 12.49, Sascha Ottolski wrote:[...]

In theory you are right. In practice we choose the path of least complexity - 
it's good enough for 98% of the cases...
[...]

That would imply maintaining some sort of queue (general and/or per-server) in 
Pound, which is exactly the complexity we avoid now.

As things stand Pound just randomly distributes requests to the back-ends 
according to the priorities you defined. Load, response time and queue size 
are not checked, measured or taken into account.[...]