> 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
