Re: [squid-users] peer selection with weight=N

From: H <hm_at_hm.net.br>
Date: Fri, 19 Feb 2010 03:08:34 -0200

>>
>> Does weight=N influence round-robin selection algorithm?
>
> Yes.
>
>> But firstable, does weight has the same definition for ICP and http
>> (no-query)
>> protocol?
>
> Yes, but what is being weighted differs slightly so proportions differ
> somewhat for the same weight in different peering protocols.
>

thank's, so far so good, but look what I get here

I have a transparent squid in front of the client network and three parents
connected to different upstream providers. All of them are connected locally
over Gigabit Eth. No mentionable delay between them, even under peak load what
is about 50-60Mbit/s through the transsparent squid box. Left to say that the
transparent proxy has always_direct deny and never_direct_allow in it

Thing is, all three as parent with no-query round-robin get equal load as
supposed, but, giving one (any) of them weight=2 makes no difference, still
gets the same load.

So I thought doing this

cache_peer parent_IP parent tport uport no-query [weight=2]
cache_peer parent_IP parent tport uport no-query round-robin
cache_peer parent_IP parent tport uport no-query round-robin

with or without weight the first gets all load, the other two are practically
never requested, no I/O traffic. To complete this, I tried any combination
without round-robin

when I disconnect the first parent from it's upstream link, navigation failes,
when I shut squid down on it, it rolls over to the second and third and does
round-robin as supposed. So I added monitorurl to the first and the failover
works BUT it never comes back to query the first.

Long story, resuming:

Coming back to query a parent with temp failing uplink only works if
round-robin is not present

round-robin with any weight for any of the parents does not divide the load in
any form and may disable failure detection

I noticed this since dezember and can not say if or when the problem started
because I had no upstream link failure before. So 2.7-STABLE7 had this problem
already.

as last try, I configured:

cache_peer parent_IP parent tport uport [no-query] [monitor-options]
cache_peer parent_IP sibling tport uport [no-query] [round-robin] [allow-miss]
cache_peer parent_IP sibling tport uport [no-query] [round-robin] [allow-miss]

which also works as long as everything is online. Whatever options are set as
expressed with [], soon the first parent or its uplink fail the siblings deny
access completely. Of course miss_access peer allow is set properly, they do
not serve misses, either with no-query nor icp. Seems sibling operation does
not work at all for misses.

I have additional cache_peer_access acls and other rules which might influence
peer selectin but disabled tem all for the described tests, the only two
regarding lines on the transparent proxy are always_direct deny and
never_direct allow, disabling these the transparent proxy goes direct and
client navigation do not fail what is good but not what I want (direct)

So I guess I am doing something very stupid or there is something wrong with
the round-robin option right?

H
(17)8111.3300
Received on Fri Feb 19 2010 - 05:08:50 MST

This archive was generated by hypermail 2.2.0 : Sat Feb 20 2010 - 12:00:05 MST