>> >> 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
