[squid-users] cache_peer weighting
Hi Guys, Wanted to double check I hadn't screwed up my config lines before dropping a bug report I've got some of my parent's configured with weight's, as we're trying out some performance optimizing code on perlbal... thing is, setting a weight in squid doesn't seem to make a difference to the number of requests that squid sends back to the parent. This is Squid-2.6STABLE17. [EMAIL PROTECTED] ~]# grep perlbal1-80 /squidperlbal | wc -l 2 [EMAIL PROTECTED] ~]# grep perlbal2-80 /squidperlbal | wc -l 248 [EMAIL PROTECTED] ~]# grep -v perlbal[12]-80 /squidperlbal | wc -l 750 --I expected at least the inverse of the above, as unless my understanding of squid weighting is completely incorrect, a weight of 100 should mean that peer is being used for 100 times more connections than the weight=1 (default weight) peers, no? Squid is configured with the following: ###ws.audioscrobbler.com & mainsite cache_peer 10.0.0.14 parent 80 0 no-query originserver no-digest no-netdb-exchange name=saruman2-80 round-robin cache_peer_access saruman2-80 allow mainsite cache_peer 10.0.0.14 parent 80 0 no-query originserver no-digest no-netdb-exchange name=saruman2-81 round-robin cache_peer_access saruman2-81 allow mainsite cache_peer 10.0.0.35 parent 80 0 no-query originserver no-digest no-netdb-exchange name=perlbal1-80 round-robin weight=100 cache_peer_access perlbal1-80 allow mainsite cache_peer 10.0.0.35 parent 81 0 no-query originserver no-digest no-netdb-exchange name=perlbal1-81 round-robin cache_peer_access perlbal1-81 allow mainsite cache_peer 10.0.0.114 parent 80 0 no-query originserver no-digest no-netdb-exchange name=perlbal2-80 round-robin weight=100 cache_peer_access perlbal2-80 allow mainsite cache_peer 10.0.0.114 parent 81 0 no-query originserver no-digest no-netdb-exchange name=perlbal2-81 round-robin cache_peer_access perlbal2-81 allow mainsite cache_peer 10.0.0.114 parent 82 0 no-query originserver no-digest no-netdb-exchange name=perlbal2-82 round-robin cache_peer_access perlbal2-82 allow mainsite cache_peer 10.0.0.114 parent 83 0 no-query originserver no-digest no-netdb-exchange name=perlbal2-83 round-robin cache_peer_access perlbal2-83 allow mainsite ###ws.audioscrobbler.com & mainsite Ends I also tried removing round-robin, in case that was screwing up the config, however, i found that this merely means all requests go to saruman2-80. Thanks! -- Tony Dodd, Systems Administrator Last.fm | http://www.last.fm Karen House 1-11 Baches Street London N1 6DL check out my music taste at: http://www.last.fm/user/hawkeviper
Re: [squid-users] cache_peer weighting
> Hi Guys, > > Wanted to double check I hadn't screwed up my config lines before > dropping a bug report Good choice. :-) round-robin == round-robin: each server trued in sequence until all have bee tried then repeats. No weighting there. IIRC Squid3.0 introduces weighted-round-robin for this purpose. Otherwise there is CARP in 2.6. Amos > > I've got some of my parent's configured with weight's, as we're trying > out some performance optimizing code on perlbal... thing is, setting a > weight in squid doesn't seem to make a difference to the number of > requests that squid sends back to the parent. This is Squid-2.6STABLE17. > > [EMAIL PROTECTED] ~]# grep perlbal1-80 /squidperlbal | wc -l > 2 > [EMAIL PROTECTED] ~]# grep perlbal2-80 /squidperlbal | wc -l > 248 > [EMAIL PROTECTED] ~]# grep -v perlbal[12]-80 /squidperlbal | wc -l > 750 > > --I expected at least the inverse of the above, as unless my > understanding of squid weighting is completely incorrect, a weight of > 100 should mean that peer is being used for 100 times more connections > than the weight=1 (default weight) peers, no? > > Squid is configured with the following: > > ###ws.audioscrobbler.com & mainsite > cache_peer 10.0.0.14 parent 80 0 no-query originserver no-digest > no-netdb-exchange name=saruman2-80 round-robin > cache_peer_access saruman2-80 allow mainsite > > cache_peer 10.0.0.14 parent 80 0 no-query originserver no-digest > no-netdb-exchange name=saruman2-81 round-robin > cache_peer_access saruman2-81 allow mainsite > > cache_peer 10.0.0.35 parent 80 0 no-query originserver no-digest > no-netdb-exchange name=perlbal1-80 round-robin weight=100 > cache_peer_access perlbal1-80 allow mainsite > > cache_peer 10.0.0.35 parent 81 0 no-query originserver no-digest > no-netdb-exchange name=perlbal1-81 round-robin > cache_peer_access perlbal1-81 allow mainsite > > cache_peer 10.0.0.114 parent 80 0 no-query originserver no-digest > no-netdb-exchange name=perlbal2-80 round-robin weight=100 > cache_peer_access perlbal2-80 allow mainsite > > cache_peer 10.0.0.114 parent 81 0 no-query originserver no-digest > no-netdb-exchange name=perlbal2-81 round-robin > cache_peer_access perlbal2-81 allow mainsite > > cache_peer 10.0.0.114 parent 82 0 no-query originserver no-digest > no-netdb-exchange name=perlbal2-82 round-robin > cache_peer_access perlbal2-82 allow mainsite > > cache_peer 10.0.0.114 parent 83 0 no-query originserver no-digest > no-netdb-exchange name=perlbal2-83 round-robin > cache_peer_access perlbal2-83 allow mainsite > ###ws.audioscrobbler.com & mainsite Ends > > I also tried removing round-robin, in case that was screwing up the > config, however, i found that this merely means all requests go to > saruman2-80. > > Thanks! > -- > Tony Dodd, Systems Administrator > > Last.fm | http://www.last.fm > Karen House 1-11 Baches Street > London N1 6DL > > check out my music taste at: > http://www.last.fm/user/hawkeviper >
Re: [squid-users] cache_peer weighting
Amos Jeffries wrote: Hi Guys, Wanted to double check I hadn't screwed up my config lines before dropping a bug report Good choice. :-) round-robin == round-robin: each server trued in sequence until all have bee tried then repeats. No weighting there. IIRC Squid3.0 introduces weighted-round-robin for this purpose. Otherwise there is CARP in 2.6. Amos Hey Amos, Hmmm, so the only way for weighting cache_peers in 2.6 is with CARP? The config manual seems to suggest otherwise: "cache_peer 172.16.1.123 sibling 3129 5500 weight=2" Or am I assuming too much here? I could be getting the wrong end of the stick; but it seemed like using a similar cache_peer entries to the above, but with a couple having the weight=100 didn't seem to change the way squid was choosing the cache_peer to use. Thanks! -- Tony Dodd, Systems Administrator Last.fm | http://www.last.fm Karen House 1-11 Baches Street London N1 6DL check out my music taste at: http://www.last.fm/user/hawkeviper
Re: [squid-users] cache_peer weighting
> Amos Jeffries wrote: >>> Hi Guys, >>> >>> Wanted to double check I hadn't screwed up my config lines before >>> dropping a bug report >> >> Good choice. :-) >> >> round-robin == round-robin: each server trued in sequence until all have >> bee tried then repeats. No weighting there. >> >> IIRC Squid3.0 introduces weighted-round-robin for this purpose. >> Otherwise >> there is CARP in 2.6. >> >> Amos >> > > Hey Amos, > > Hmmm, so the only way for weighting cache_peers in 2.6 is with CARP? No, its just the most modern and one thats shown some promise in recent benchmarking earlier this year by a large-scale user. Thier exact results are buried back in the mailing list somewhere. There are other algorithms, with different properties that suite differing siutaions. > The config manual seems to suggest otherwise: > > "cache_peer 172.16.1.123 sibling 3129 5500 weight=2" > > Or am I assuming too much here? I could be getting the wrong end of the > stick; but it seemed like using a similar cache_peer entries to the > above, but with a couple having the weight=100 didn't seem to change the > way squid was choosing the cache_peer to use. The different algorithms all work their own way, with different inputs. round-robin you were trying is an algorithm that ignores weight. I think carp, closest-only, multicast-responder (weighted using ttl=) are weighted in 2.6. All the closest-* ones use live network loading instead of a fixed weight. I'm not sure which config manual you got that from. The Official Authoritative one does not include that text. http://www.squid-cache.org/Versions/v2/2.6/cfgman/cache_peer.html http://www.squid-cache.org/Versions/v3/3.0/cfgman/cache_peer.html Amos
Re: [squid-users] cache_peer weighting
Amos Jeffries wrote: No, its just the most modern and one thats shown some promise in recent benchmarking earlier this year by a large-scale user. Thier exact results are buried back in the mailing list somewhere. There are other algorithms, with different properties that suite differing siutaions. I'll take a look at CARP, thanks =] The config manual seems to suggest otherwise: "cache_peer 172.16.1.123 sibling 3129 5500 weight=2" Or am I assuming too much here? I could be getting the wrong end of the stick; but it seemed like using a similar cache_peer entries to the above, but with a couple having the weight=100 didn't seem to change the way squid was choosing the cache_peer to use. I'm not sure which config manual you got that from. The Official Authoritative one does not include that text. http://www.squid-cache.org/Versions/v2/2.6/cfgman/cache_peer.html http://www.squid-cache.org/Versions/v3/3.0/cfgman/cache_peer.html ViSolve.. heh Thanks again Amos! -- Tony Dodd, Systems Administrator Last.fm | http://www.last.fm Karen House 1-11 Baches Street London N1 6DL check out my music taste at: http://www.last.fm/user/hawkeviper
Re: [squid-users] cache_peer weighting
On Tue, 18 Dec 2007 13:53:42 +1300 (NZDT) "Amos Jeffries" <[EMAIL PROTECTED]> wrote: > > IIRC Squid3.0 introduces weighted-round-robin for this purpose. > Otherwise there is CARP in 2.6. So, I've implemented CARP, but I'm seeing some odd behavior... Given the following config lines: ###Userserve cache_peer 10.0.20.1 parent 81 0 no-query originserver no-digest no-netdb-exchange name=userserve1-81 carp weight=1 cache_peer_domain userserve1-81 userserve.last.fm cache_peer 10.0.20.1 parent 82 0 no-query originserver no-digest no-netdb-exchange name=userserve1-82 carp weight=1 cache_peer_domain userserve1-82 userserve.last.fm cache_peer 10.0.20.1 parent 83 0 no-query originserver no-digest no-netdb-exchange name=userserve1-83 carp weight=1 cache_peer_domain userserve1-83 userserve.last.fm cache_peer 10.0.20.1 parent 84 0 no-query originserver no-digest no-netdb-exchange name=userserve1-84 carp weight=1 cache_peer_domain userserve1-84 userserve.last.fm cache_peer 10.0.20.2 parent 81 0 no-query originserver no-digest no-netdb-exchange name=userserve2-81 carp weight=1 cache_peer_domain userserve2-81 userserve.last.fm cache_peer 10.0.20.2 parent 82 0 no-query originserver no-digest no-netdb-exchange name=userserve2-82 carp weight=1 cache_peer_domain userserve2-82 userserve.last.fm cache_peer 10.0.20.2 parent 83 0 no-query originserver no-digest no-netdb-exchange name=userserve2-83 carp weight=1 cache_peer_domain userserve2-83 userserve.last.fm cache_peer 10.0.20.2 parent 84 0 no-query originserver no-digest no-netdb-exchange name=userserve2-84 carp weight=1 cache_peer_domain userserve2-84 userserve.last.fm ###Userserve Ends I had expected to get an equal number of connections spread across each cache_peer instance (we run one perlbal instance per core on each of the machines). What I'm seeing though, is that squid is only connecting to two of the above, and in both cases, the first occurrence of each: [EMAIL PROTECTED] ~]# sort /userservestats | uniq -c 25244 CARP/userserve1-81 25949 CARP/userserve2-81 Does squid, or rather the squid CARP code have something in it which allows it to only use one port per IP address? Thanks! -- Tony Dodd, Systems Administrator Last.fm | http://www.last.fm Karen House 1-11 Baches Street London N1 6DL check out my music taste at: http://www.last.fm/user/hawkeviper
Re: [squid-users] cache_peer weighting
> On Tue, 18 Dec 2007 13:53:42 +1300 (NZDT) > "Amos Jeffries" <[EMAIL PROTECTED]> wrote: > >> >> IIRC Squid3.0 introduces weighted-round-robin for this purpose. >> Otherwise there is CARP in 2.6. > > So, I've implemented CARP, but I'm seeing some odd behavior... > > Given the following config lines: > > > ###Userserve > cache_peer 10.0.20.1 parent 81 0 no-query originserver no-digest > no-netdb-exchange name=userserve1-81 carp weight=1 cache_peer_domain > userserve1-81 userserve.last.fm > > cache_peer 10.0.20.1 parent 82 0 no-query originserver no-digest > no-netdb-exchange name=userserve1-82 carp weight=1 cache_peer_domain > userserve1-82 userserve.last.fm > > cache_peer 10.0.20.1 parent 83 0 no-query originserver no-digest > no-netdb-exchange name=userserve1-83 carp weight=1 cache_peer_domain > userserve1-83 userserve.last.fm > > cache_peer 10.0.20.1 parent 84 0 no-query originserver no-digest > no-netdb-exchange name=userserve1-84 carp weight=1 cache_peer_domain > userserve1-84 userserve.last.fm > > cache_peer 10.0.20.2 parent 81 0 no-query originserver no-digest > no-netdb-exchange name=userserve2-81 carp weight=1 cache_peer_domain > userserve2-81 userserve.last.fm > > cache_peer 10.0.20.2 parent 82 0 no-query originserver no-digest > no-netdb-exchange name=userserve2-82 carp weight=1 cache_peer_domain > userserve2-82 userserve.last.fm > > cache_peer 10.0.20.2 parent 83 0 no-query originserver no-digest > no-netdb-exchange name=userserve2-83 carp weight=1 cache_peer_domain > userserve2-83 userserve.last.fm > > cache_peer 10.0.20.2 parent 84 0 no-query originserver no-digest > no-netdb-exchange name=userserve2-84 carp weight=1 cache_peer_domain > userserve2-84 userserve.last.fm > ###Userserve Ends > > I had expected to get an equal number of connections spread across each > cache_peer instance (we run one perlbal instance per core on each of > the machines). What I'm seeing though, is that squid is only > connecting to two of the above, and in both cases, the first occurrence > of each: > > [EMAIL PROTECTED] ~]# sort /userservestats | uniq -c > 25244 CARP/userserve1-81 > 25949 CARP/userserve2-81 > > Does squid, or rather the squid CARP code have something in it which > allows it to only use one port per IP address? Did you move to 2.6 in the process? I found that carp is accepted in 2.5 but marked experimental and before many bugs fixes that went into 2.6. Try adding debug_options ALL,1, 39,5 to squid.conf and see what pops into cache.log Amos
Re: [squid-users] cache_peer weighting
Amos Jeffries wrote: Did you move to 2.6 in the process? I found that carp is accepted in 2.5 but marked experimental and before many bugs fixes that went into 2.6. Try adding debug_options ALL,1, 39,5 to squid.conf and see what pops into cache.log I've been running 2.6 for a while; and currently testing 2.HEAD & 3.0STABLE1 on two machines. I've dropped a bugzilla for this, along with a patch to modify the functionality to include http_port within the carp hashing code. It enables a squid config option of 'carp_hash_port on/off': http://www.squid-cache.org/bugs/show_bug.cgi?id=2153 Log output previously looked like: 2007/12/19 03:05:04| carpSelectParent: 10.0.20.1 combined_hash 4266296709 score 4069969201 2007/12/19 03:05:04| carpSelectParent: 10.0.20.1 combined_hash 4266296709 score 4069969201 2007/12/19 03:05:04| carpSelectParent: 10.0.20.1 combined_hash 4266296709 score 4069969201 2007/12/19 03:05:04| carpSelectParent: 10.0.20.1 combined_hash 4266296709 score 4069969201 2007/12/19 03:05:04| carpSelectParent: 10.0.20.2 combined_hash 1829481 score 1745291 2007/12/19 03:05:04| carpSelectParent: 10.0.20.2 combined_hash 1829481 score 1745291 2007/12/19 03:05:04| carpSelectParent: 10.0.20.2 combined_hash 1829481 score 1745291 2007/12/19 03:05:04| carpSelectParent: 10.0.20.2 combined_hash 1829481 score 1745291 and 2007/12/19 03:06:57| carpSelectParent: selected 10.0.20.1 2007/12/19 03:06:57| carpSelectParent: selected 10.0.20.2 2007/12/19 03:06:57| carpSelectParent: selected 10.0.20.2 2007/12/19 03:06:57| carpSelectParent: selected 10.0.20.2 2007/12/19 03:06:57| carpSelectParent: selected 10.0.20.1 2007/12/19 03:06:58| carpSelectParent: selected 10.0.20.2 2007/12/19 03:06:58| carpSelectParent: selected 10.0.20.1 2007/12/19 03:06:58| carpSelectParent: selected 10.0.20.1 2007/12/19 03:06:59| carpSelectParent: selected 10.0.20.2 2007/12/19 03:06:59| carpSelectParent: selected 10.0.20.2 and now looks like: 2007/12/19 04:45:28| carpSelectParent: 10.0.20.1:82 combined_hash 1266692258 score 1208401297 2007/12/19 04:45:28| carpSelectParent: 10.0.20.1:81 combined_hash 1239382347 score 1182348140 2007/12/19 04:45:28| carpSelectParent: 10.0.20.1:83 combined_hash 223054348 score 212789777 2007/12/19 04:45:28| carpSelectParent: 10.0.20.1:84 combined_hash 251909667 score 240317225 2007/12/19 04:45:28| carpSelectParent: 10.0.20.2:81 combined_hash 223054348 score 212789777 2007/12/19 04:45:28| carpSelectParent: 10.0.20.2:82 combined_hash 251909667 score 240317225 2007/12/19 04:45:28| carpSelectParent: 10.0.20.2:83 combined_hash 281703136 score 268739651 2007/12/19 04:45:28| carpSelectParent: 10.0.20.2:84 combined_hash 2862529730 score 2730801121 and 2007/12/19 04:39:43| carpSelectParent: selected 10.0.20.2:83 2007/12/19 04:39:43| carpSelectParent: selected 10.0.20.2:84 2007/12/19 04:39:43| carpSelectParent: selected 10.0.20.1:84 2007/12/19 04:39:43| carpSelectParent: selected 10.0.20.1:82 2007/12/19 04:39:43| carpSelectParent: selected 10.0.20.1:84 2007/12/19 04:39:44| carpSelectParent: selected 10.0.20.2:81 2007/12/19 04:39:44| carpSelectParent: selected 10.0.20.1:83 2007/12/19 04:39:44| carpSelectParent: selected 10.0.20.2:82 2007/12/19 04:39:44| carpSelectParent: selected 10.0.20.1:84 2007/12/19 04:39:44| carpSelectParent: selected 10.0.20.2:81 -- Tony Dodd, Systems Administrator Last.fm | http://www.last.fm Karen House 1-11 Baches Street London N1 6DL check out my music taste at: http://www.last.fm/user/hawkeviper
