Re: [squid-users] Some queries about cache_peer

From: Amos Jeffries <squid3_at_treenet.co.nz>
Date: Thu, 31 Jul 2008 23:39:54 +1200

bijayant kumar wrote:
>> From: Amos Jeffries <squid3_at_treenet.co.nz>
>> Subject: Re: [squid-users] Some queries about cache_peer
>> To: bijayant4u_at_yahoo.com
>> Cc: "squid users" <squid-users_at_squid-cache.org>
>> Date: Thursday, 31 July, 2008, 9:31 AM
>>> Hello list,
>>>
>>> I tried to set up cache_peer, but i could not
>> understand that it has setup
>>> or not. Please give some inputs.
>>>
>>> Scenario:-
>>>
>>> I have setup three proxy-servers.squid 3.0.7 Stable
>>> proxy1 192.168.99.134
>>> proxy2 192.168.99.135
>>> proxy3 192.168.99.121
>>>
>>> Lan Computer 192.168.99.23.
>>>
>>> On my Lan Computer, i have configured proxy in my
>> browser as
>>> 192.168.99.134 ie proxy1. All request first go to
>> proxy1.
>>> In Proxy1 squid.conf:-
>>> cache_peer 192.168.99.135 parent 3128 3130
>> proxy-only default
>>> cache_peer 192.168.99.121 parent 3128 3130
>> proxy-only
>>> cache_peer_domain 192.168.99.135 .com
>>> cache_peer_domain 192.168.99.121 .net
>>>
>>> In proxy2 and proxy3 no cache_peer is configured.
>>>
>>> I can browse the web. But i didnt understand the
>> working. I have some
>>> queries regarding this scenario:
>>> If the page is not in any of the proxy server, then
>> which proxy server
>>> will go to internet and fetch for the user. I mean if
>> user access any
>>> ".net" domain then the request will come to
>> the proxy1 first, it will
>>> query to the proxy3, if its there it will be delivered
>> else the page will
>>> be fetched from the internet ,Same is for the
>> ".com" domain right?
>>
>> Usually. If netdb/icmp has been enabled squid will keep
>> records of
>> response times and go to whichever of peer/web responds
>> fastest. thinking
>> fastest available service is usually best to use.
>>
>> Check your access.log for info on which is being selected
>> for each request.
>>
>>> Then my question is,
>>> 1) which server will query to the internet for the
>> page which is not in
>>> the cache ie ".net" dedicated server or the
>> main proxy1 server?
>>
>> Under only cache_peer_domain, maybe both. Use
>> 'never_direct' to force
>> requests to go via peers.
>>
> If i use 'never_direct' option then if parent cache servers will go down then no body will be able to browse the web. And if i will not use 'never_direct' option then fetching of object will be done by proxy1,if object not found in any cache(proxy2/proxy3), am i right?

Yes.

>
>>> 2) The new page will be written to the which cache,
>> proxy1 or
>>> proxy2/proxy3
>> 'proxy-only' prevents caching at proxy1 if request
>> came from peer. If
>> request came from web DIRECT then it can be cached at
>> proxy1 and used
>> later.
> In my configuration, proxy1 will query to the internet for new objects and hence the cache will be populated of proxy1 only, no matter it is of ".net" domain or of ".com" domain. Then the new entry of ".net" and ".com" domain will never be written to the cache of the dedicated caching server for the same.
> If i am right in my analogy then can you please suggest me to how to avoid this situation. I mean that ".net" cache will be written to ".net" dedicated server(proxy3) and ".com" cache will be written to the proxy2.

In squid you only have a choice of peers vs DIRECT.

Your config earlier was workable, in which case squid will make that
choice every request. Usually going peers, but sometimes going DIRECT.

Or you can force a choice yourself with never_direct (opposite is
always_direct, but its clear to me you don't want that).

It's up to you.

To decide if a cache of 100% .com traffic is worth the small risk of no
access to .com at all when proxy2 goes down. Which is only 2x the same
risk of proxy1 going down by itself anyway.

Keeping in mind that a quick admin reconfigure of proxy1 (commenting out
the proxy2 lines) can restore access while proxy2 is debugged about why
it went down.

Amos

-- 
Please use Squid 2.7.STABLE3 or 3.0.STABLE8
Received on Thu Jul 31 2008 - 11:39:55 MDT

This archive was generated by hypermail 2.2.0 : Thu Jul 31 2008 - 12:00:05 MDT