Re: [squid-users] squid accel peer load balancing weighted round robin?

> Sylvain Viart wrote:
>> Hi Chris,
>> Chris Robertson a écrit :
>>>> I've a squid Version 2.6.STABLE16
>>>> with the following config accel mode design:
>>>>
>>>> proxy ----> php-01..php-08
>>>>
>>>> php are apache server no slibing proxy.
>>>
>>> If things haven't changed, weight only works with ICP. Basically an
>>> ICP query is sent out, and the weight is added to an internal
>>> calculation based on response latency (and possibly other factors) to
>>> determine which affirmative responding ICP peer to request the actual
>>> object from.
>> Ok, that what I suppose too. weight seems to be for ICP slibing proxy.
>> What I want effectively is, weighted round robin on origin server.
>
> As far as I can tell, CARP would do that. I haven't tested it though.
>
>>
>> And it seems, that perform, round bobin as expected. But it may also
>> be disturbed by some other peer in my definition. Here is the
>> complement:
>>
>> I define 8 peer, for php content, and 1 for static content, as you can
>> see on the max-conn peer doesn't allow the same load. I first try to
>> modify the weight introducing the strange behavior I described.
>> The config I show is my new test, with url_rewriter weighted round
>> robin. Which seems to work as expected.
>
> SNIP
> Fair enough. Clever solution.
>
>>> Squid 3's conf file seems to confirm this
>>> (http://www.squid-cache.org/Versions/v3/3.0/cfgman/cache_peer.html):
>>>
>>> use 'weight=n' to affect the selection of a peer during any weighted
>>> peer-selection mechanisms. The weight must be an integer; default is
>>> 1, larger weights are favored more. This option does not affect
>>> parent selection if a peering protocol is not in use.
>> Seems also for ICP proxy, even weighted-round-robin, an squid3 option,
>> seems to be related to ICP proxy.
>
> Agreed.
>
> SNIP
>
>>>> All my test seem to show always very more load on the last peer in
>>>> the list. That why I protect with max-conn=100.
>>>
>>> How are you measuring load? Round-robin is exactly what it sounds
>>> like. Each request is sent to the next peer in line. Processing
>>> load is not taken in to consideration.
>> I measure load by looking on some MRTG like graph of all the server
>> pool. And clearly it see, than the load is badly divided on each peer.
>> But if it's supposed to work with slibing proxy, I can live with that
>> somewhat bug. :-)
>
> Very odd.
>
>>> CARP is purpose build load balancing algorithm, and as far as I know,
>>> it should work with originserver.
>>> http://docs.huihoo.com/gnu_linux/squid/html/x2398.html
>> Yep, I saw it too. Seems to be also for slibing proxy, no?
>
> Designed for sibling proxies, yes. But it doesn't seem to require ICP,
> so should work with non-ICP peers (and therefore acceleration setups).
> As I stated, I haven't tested this theory.
>

NONE of the peer selection depends on just ICP.
The weights are calculated from the accumulated sum of:
 - ICP response
 - HTCP response
 - HTTP response
 - ICMP/ping round-trip hops

and I think;
 - NetDB distance-to-origin received
 - Digest distance-to-origin received

If you are not using ICP then the ICP value stays at 0 in the sum.
Likewise for ICMP/ping, netdb, digest, etc.

Amos
Received on Wed Oct 31 2007 - 15:48:35 MDT