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.
Thanks for you comment.
Sorry they weren't more helpful.
Regards,
Sylvain.
Chris
