RE: [squid-users] Strange problem with sibling squids in accelerator mode
It seems that only if the http request is sent from same server where the squid instance has the object, then its sibling will retrieve it from this server. If the request is sent from a different box, no ICP communication goes on. Why? -Original Message- From: Lu, Roy [mailto:r...@facorelogic.com] Sent: Tuesday, June 30, 2009 5:26 PM To: squid-users@squid-cache.org Subject: RE: [squid-users] Strange problem with sibling squids in accelerator mode I am using version 3.0 stable 16. -Original Message- From: Lu, Roy [mailto:r...@facorelogic.com] Sent: Tuesday, June 30, 2009 5:24 PM To: squid-users@squid-cache.org Subject: [squid-users] Strange problem with sibling squids in accelerator mode Hi, I encountered a strange problem in using sibling squids as accelerators. I have two accelerator squids, A and B (on two different boxes). They are set up as sibling cache peers which both point to the same parent cache_peer origin content server. I used the following commands to run my test: 1. Load an object into A: %squidclient -h host.name.of.A URL 2. Purge the object from B: %squidclient -h host.name.of.B -m PURGE URL 3. Double check to make sure A has the object and B does not: %squidclient -h host.name.of.A -m HEAD -H Cache-Control: only-if-cached\n URL Resulted in TCP_MEM_HIT %squidclient -h host.name.of.B -m HEAD -H Cache-Control: only-if-cached\n URL Resulted in TCP_MISS 4. Request the object from B: %squidclient -h host.name.of.B URL Now the strange problem comes in. If I run the last step on the box A, the ICP communication occurs, and in A's log I see UDP_HIT and TCP_MEM_HIT, and in B's log I see TCP_MISS and SIBLING_HIT. However, if I run the last step in B, then there is no ICP communication, squid B simply goes to the parent origin server to get the object (in B's log FIRST_UP_PARENT and nothing in A's log). When I run the same test with squidclient on a third machine, the result is negative too. So it seems that only if I run the squidclient utility on the same box where the cached object is, then its sibling cache will retrieve the object from this box. The configuration for Squid A is: #=== # ACL changes #=== # acl for purge method acl acl_purge method purge # acl for origin app server acl acl_gpl_app_servers dstdomain vmprodcagpcna04.firstamdata.net # acl for cache peer squid server acl acl_gpl_cache_sibling src host.name.of.A #=== # http_access changes #=== # allow purge method from localhost or sibling http_access allow acl_purge localhost http_access allow acl_purge acl_gpl_cache_sibling http_access deny acl_purge # allow http access to app servers and from cache sibling http_access allow acl_gpl_app_servers http_access allow acl_gpl_cache_sibling #=== # icp_access changes #=== # allow icp queries from cache sibling icp_access allow acl_gpl_cache_sibling #=== # cache_peer changes #=== cache_peer vmprodcagpcna04.firstamdata.net parent 7533 0 no-query originserver name=cp_gpl_app_servers cache_peer host.name.of.A sibling 3128 3130 name=cp_gpl_cache_sibling proxy-only #=== # cache_peer_access changes #=== # Allow peer connection to the origin app server and sibling cache peer cache_peer_access cp_gpl_app_servers allow acl_gpl_app_servers cache_peer_access cp_gpl_cache_sibling allow acl_gpl_cache_sibling Configuration for B is almost identical except the host.name.of.A in the acl and cache_peer tags is switched with B's. Can someone point out what might be the problem here? Thanks. Roy ** This message may contain confidential or proprietary information intended only for the use of the addressee(s) named above or may contain information that is legally privileged. If you are not the intended addressee, or the person responsible for delivering it to the intended addressee, you are hereby notified that reading, disseminating, distributing or copying this message is strictly prohibited. If you have received this message by mistake, please
Re: [squid-users] Strange problem with sibling squids in accelerator mode
Lu, Roy wrote: Hi, I encountered a strange problem in using sibling squids as accelerators. I have two accelerator squids, A and B (on two different boxes). They are set up as sibling cache peers which both point to the same parent cache_peer origin content server. I used the following commands to run my test: 1. Load an object into A: %squidclient -h host.name.of.A URL 2. Purge the object from B: %squidclient -h host.name.of.B -m PURGE URL 3. Double check to make sure A has the object and B does not: %squidclient -h host.name.of.A -m HEAD -H Cache-Control: only-if-cached\n URL Resulted in TCP_MEM_HIT %squidclient -h host.name.of.B -m HEAD -H Cache-Control: only-if-cached\n URL Resulted in TCP_MISS 4. Request the object from B: %squidclient -h host.name.of.B URL Now the strange problem comes in. If I run the last step on the box A, the ICP communication occurs, and in A's log I see UDP_HIT and TCP_MEM_HIT, and in B's log I see TCP_MISS and SIBLING_HIT. However, if I run the last step in B, then there is no ICP communication, squid B simply goes to the parent origin server to get the object (in B's log FIRST_UP_PARENT and nothing in A's log). When I run the same test with squidclient on a third machine, the result is negative too. So it seems that only if I run the squidclient utility on the same box where the cached object is, then its sibling cache will retrieve the object from this box. I think this is due to your cache_peer and/or cache_peer_access lines... The configuration for Squid A is: #=== # ACL changes #=== # acl for purge method acl acl_purge method purge # acl for origin app server acl acl_gpl_app_servers dstdomain vmprodcagpcna04.firstamdata.net # acl for cache peer squid server acl acl_gpl_cache_sibling src host.name.of.A #=== # http_access changes #=== # allow purge method from localhost or sibling http_access allow acl_purge localhost http_access allow acl_purge acl_gpl_cache_sibling http_access deny acl_purge # allow http access to app servers and from cache sibling http_access allow acl_gpl_app_servers http_access allow acl_gpl_cache_sibling #=== # icp_access changes #=== # allow icp queries from cache sibling icp_access allow acl_gpl_cache_sibling #=== # cache_peer changes #=== cache_peer vmprodcagpcna04.firstamdata.net parent 7533 0 no-query originserver name=cp_gpl_app_servers cache_peer host.name.of.A sibling 3128 3130 name=cp_gpl_cache_sibling proxy-only Did you REALLY set Squid A up as a sibling to ITSELF? #=== # cache_peer_access changes #=== # Allow peer connection to the origin app server and sibling cache peer cache_peer_access cp_gpl_app_servers allow acl_gpl_app_servers cache_peer_access cp_gpl_cache_sibling allow acl_gpl_cache_sibling Assuming the cache_peer line above was a typo, and you have set Squid B as a peer, here you specifically state... allow access to the origin server if the requested domain is vmprodcagpcna04.firstamdata.net allow access to Squid B if the (original) requesting server is Squid A (implied) deny access to any peers not specified above ...which would prevent any communication between cache_peers unless the request ORIGINATES from the server specified by acl_gpl_cache_sibling. Third party, unrelated machines (clients) would never cause a peer access. I think you would be better served with... cache_peer_access cp_gpl_app_server allow acl_gpl_app_servers cache_peer_access cp_gpl_cache_sibling allow acl_gpl_app_servers ...which would allow communication to peers for ANY traffic with the destination domain you are serving. You have already specified the origin server, so Squid will go there if the page is not available from a peer (or if the peer times out, or...). Configuration for B is almost identical except the host.name.of.A in the acl and cache_peer tags is switched with B's. Can someone point out what might be the problem here? Thanks. Roy Chris
RE: [squid-users] Strange problem with sibling squids in accelerator mode
Yes, that was a typo. I tried your suggestion, and it fixed it. Thank you very much for your help! Roy -Original Message- From: Chris Robertson [mailto:crobert...@gci.net] Sent: Wednesday, July 01, 2009 1:35 PM To: squid-users@squid-cache.org Subject: Re: [squid-users] Strange problem with sibling squids in accelerator mode Lu, Roy wrote: Hi, I encountered a strange problem in using sibling squids as accelerators. I have two accelerator squids, A and B (on two different boxes). They are set up as sibling cache peers which both point to the same parent cache_peer origin content server. I used the following commands to run my test: 1. Load an object into A: %squidclient -h host.name.of.A URL 2. Purge the object from B: %squidclient -h host.name.of.B -m PURGE URL 3. Double check to make sure A has the object and B does not: %squidclient -h host.name.of.A -m HEAD -H Cache-Control: only-if-cached\n URL Resulted in TCP_MEM_HIT %squidclient -h host.name.of.B -m HEAD -H Cache-Control: only-if-cached\n URL Resulted in TCP_MISS 4. Request the object from B: %squidclient -h host.name.of.B URL Now the strange problem comes in. If I run the last step on the box A, the ICP communication occurs, and in A's log I see UDP_HIT and TCP_MEM_HIT, and in B's log I see TCP_MISS and SIBLING_HIT. However, if I run the last step in B, then there is no ICP communication, squid B simply goes to the parent origin server to get the object (in B's log FIRST_UP_PARENT and nothing in A's log). When I run the same test with squidclient on a third machine, the result is negative too. So it seems that only if I run the squidclient utility on the same box where the cached object is, then its sibling cache will retrieve the object from this box. I think this is due to your cache_peer and/or cache_peer_access lines... The configuration for Squid A is: #=== # ACL changes #=== # acl for purge method acl acl_purge method purge # acl for origin app server acl acl_gpl_app_servers dstdomain vmprodcagpcna04.firstamdata.net # acl for cache peer squid server acl acl_gpl_cache_sibling src host.name.of.A #=== # http_access changes #=== # allow purge method from localhost or sibling http_access allow acl_purge localhost http_access allow acl_purge acl_gpl_cache_sibling http_access deny acl_purge # allow http access to app servers and from cache sibling http_access allow acl_gpl_app_servers http_access allow acl_gpl_cache_sibling #=== # icp_access changes #=== # allow icp queries from cache sibling icp_access allow acl_gpl_cache_sibling #=== # cache_peer changes #=== cache_peer vmprodcagpcna04.firstamdata.net parent 7533 0 no-query originserver name=cp_gpl_app_servers cache_peer host.name.of.A sibling 3128 3130 name=cp_gpl_cache_sibling proxy-only Did you REALLY set Squid A up as a sibling to ITSELF? #=== # cache_peer_access changes #=== # Allow peer connection to the origin app server and sibling cache peer cache_peer_access cp_gpl_app_servers allow acl_gpl_app_servers cache_peer_access cp_gpl_cache_sibling allow acl_gpl_cache_sibling Assuming the cache_peer line above was a typo, and you have set Squid B as a peer, here you specifically state... allow access to the origin server if the requested domain is vmprodcagpcna04.firstamdata.net allow access to Squid B if the (original) requesting server is Squid A (implied) deny access to any peers not specified above ...which would prevent any communication between cache_peers unless the request ORIGINATES from the server specified by acl_gpl_cache_sibling. Third party, unrelated machines (clients) would never cause a peer access. I think you would be better served with... cache_peer_access cp_gpl_app_server allow acl_gpl_app_servers cache_peer_access cp_gpl_cache_sibling allow acl_gpl_app_servers ...which would allow communication to peers for ANY traffic with the destination domain you are serving. You have already specified the origin server, so Squid will go
[squid-users] Strange problem with sibling squids in accelerator mode
Hi, I encountered a strange problem in using sibling squids as accelerators. I have two accelerator squids, A and B (on two different boxes). They are set up as sibling cache peers which both point to the same parent cache_peer origin content server. I used the following commands to run my test: 1. Load an object into A: %squidclient -h host.name.of.A URL 2. Purge the object from B: %squidclient -h host.name.of.B -m PURGE URL 3. Double check to make sure A has the object and B does not: %squidclient -h host.name.of.A -m HEAD -H Cache-Control: only-if-cached\n URL Resulted in TCP_MEM_HIT %squidclient -h host.name.of.B -m HEAD -H Cache-Control: only-if-cached\n URL Resulted in TCP_MISS 4. Request the object from B: %squidclient -h host.name.of.B URL Now the strange problem comes in. If I run the last step on the box A, the ICP communication occurs, and in A's log I see UDP_HIT and TCP_MEM_HIT, and in B's log I see TCP_MISS and SIBLING_HIT. However, if I run the last step in B, then there is no ICP communication, squid B simply goes to the parent origin server to get the object (in B's log FIRST_UP_PARENT and nothing in A's log). When I run the same test with squidclient on a third machine, the result is negative too. So it seems that only if I run the squidclient utility on the same box where the cached object is, then its sibling cache will retrieve the object from this box. The configuration for Squid A is: #=== # ACL changes #=== # acl for purge method acl acl_purge method purge # acl for origin app server acl acl_gpl_app_servers dstdomain vmprodcagpcna04.firstamdata.net # acl for cache peer squid server acl acl_gpl_cache_sibling src host.name.of.A #=== # http_access changes #=== # allow purge method from localhost or sibling http_access allow acl_purge localhost http_access allow acl_purge acl_gpl_cache_sibling http_access deny acl_purge # allow http access to app servers and from cache sibling http_access allow acl_gpl_app_servers http_access allow acl_gpl_cache_sibling #=== # icp_access changes #=== # allow icp queries from cache sibling icp_access allow acl_gpl_cache_sibling #=== # cache_peer changes #=== cache_peer vmprodcagpcna04.firstamdata.net parent 7533 0 no-query originserver name=cp_gpl_app_servers cache_peer host.name.of.A sibling 3128 3130 name=cp_gpl_cache_sibling proxy-only #=== # cache_peer_access changes #=== # Allow peer connection to the origin app server and sibling cache peer cache_peer_access cp_gpl_app_servers allow acl_gpl_app_servers cache_peer_access cp_gpl_cache_sibling allow acl_gpl_cache_sibling Configuration for B is almost identical except the host.name.of.A in the acl and cache_peer tags is switched with B's. Can someone point out what might be the problem here? Thanks. Roy ** This message may contain confidential or proprietary information intended only for the use of the addressee(s) named above or may contain information that is legally privileged. If you are not the intended addressee, or the person responsible for delivering it to the intended addressee, you are hereby notified that reading, disseminating, distributing or copying this message is strictly prohibited. If you have received this message by mistake, please immediately notify us by replying to the message and delete the original message and any copies immediately thereafter. Thank you. ** FACLD
RE: [squid-users] Strange problem with sibling squids in accelerator mode
I am using version 3.0 stable 16. -Original Message- From: Lu, Roy [mailto:r...@facorelogic.com] Sent: Tuesday, June 30, 2009 5:24 PM To: squid-users@squid-cache.org Subject: [squid-users] Strange problem with sibling squids in accelerator mode Hi, I encountered a strange problem in using sibling squids as accelerators. I have two accelerator squids, A and B (on two different boxes). They are set up as sibling cache peers which both point to the same parent cache_peer origin content server. I used the following commands to run my test: 1. Load an object into A: %squidclient -h host.name.of.A URL 2. Purge the object from B: %squidclient -h host.name.of.B -m PURGE URL 3. Double check to make sure A has the object and B does not: %squidclient -h host.name.of.A -m HEAD -H Cache-Control: only-if-cached\n URL Resulted in TCP_MEM_HIT %squidclient -h host.name.of.B -m HEAD -H Cache-Control: only-if-cached\n URL Resulted in TCP_MISS 4. Request the object from B: %squidclient -h host.name.of.B URL Now the strange problem comes in. If I run the last step on the box A, the ICP communication occurs, and in A's log I see UDP_HIT and TCP_MEM_HIT, and in B's log I see TCP_MISS and SIBLING_HIT. However, if I run the last step in B, then there is no ICP communication, squid B simply goes to the parent origin server to get the object (in B's log FIRST_UP_PARENT and nothing in A's log). When I run the same test with squidclient on a third machine, the result is negative too. So it seems that only if I run the squidclient utility on the same box where the cached object is, then its sibling cache will retrieve the object from this box. The configuration for Squid A is: #=== # ACL changes #=== # acl for purge method acl acl_purge method purge # acl for origin app server acl acl_gpl_app_servers dstdomain vmprodcagpcna04.firstamdata.net # acl for cache peer squid server acl acl_gpl_cache_sibling src host.name.of.A #=== # http_access changes #=== # allow purge method from localhost or sibling http_access allow acl_purge localhost http_access allow acl_purge acl_gpl_cache_sibling http_access deny acl_purge # allow http access to app servers and from cache sibling http_access allow acl_gpl_app_servers http_access allow acl_gpl_cache_sibling #=== # icp_access changes #=== # allow icp queries from cache sibling icp_access allow acl_gpl_cache_sibling #=== # cache_peer changes #=== cache_peer vmprodcagpcna04.firstamdata.net parent 7533 0 no-query originserver name=cp_gpl_app_servers cache_peer host.name.of.A sibling 3128 3130 name=cp_gpl_cache_sibling proxy-only #=== # cache_peer_access changes #=== # Allow peer connection to the origin app server and sibling cache peer cache_peer_access cp_gpl_app_servers allow acl_gpl_app_servers cache_peer_access cp_gpl_cache_sibling allow acl_gpl_cache_sibling Configuration for B is almost identical except the host.name.of.A in the acl and cache_peer tags is switched with B's. Can someone point out what might be the problem here? Thanks. Roy ** This message may contain confidential or proprietary information intended only for the use of the addressee(s) named above or may contain information that is legally privileged. If you are not the intended addressee, or the person responsible for delivering it to the intended addressee, you are hereby notified that reading, disseminating, distributing or copying this message is strictly prohibited. If you have received this message by mistake, please immediately notify us by replying to the message and delete the original message and any copies immediately thereafter. Thank you. ** FACLD
