Re: [squid-users] Four squid scenarios

From: Amos Jeffries <squid3_at_treenet.co.nz>
Date: Wed, 20 Oct 2010 02:02:35 +0000

On Tue, 19 Oct 2010 20:30:47 +0200, Konrado Z <konradoz_at_partyinfo.com.pl>
wrote:
> Thanks for your response and explanation.
>
> OK, and what's about situation where there are 2 parents who are
> siblings at the sime time, and one proxy server under them. What I
> mean is:
>
>
> P1 ----- P2
> \ /
> \ /
> P3
> |
> host
>
> and P1, and P2 are connected to the Internet.

Same as scenario (3) earlier. A compound of scenarios (1) and (2).

In scenario (3) DNS load-balancing determined which proxy the host
connected to.
In the above (scenario 5?) squid.conf cache_peer entries do the
load-balancing instead to determine which P1/P2 the P3 connects to.

Amos

>
> 2010/10/19 Amos Jeffries <squid3_at_treenet.co.nz>:
>> On Mon, 18 Oct 2010 20:50:02 +0200, Konrado Z
<konradoz_at_partyinfo.com.pl>
>> wrote:
>>> Hello,
>>>
>>> I have to consider four scenarios:
>>>
>>> 1) http://img230.imageshack.us/img230/4172/52435275.jpg
>>> 2) http://img2.imageshack.us/img2/6708/42467335.jpg
>>> 3) http://img213.imageshack.us/img213/3600/77675899.jpg
>>> 4) http://img84.imageshack.us/img84/7221/12837089.jpg
>>> Host is connected only to one proxy (I think it does not matter to
>>> which one). But proxies servers are connetected to each other.
>>>
>>> The question is, on which proxy server the website requested will be
>>> cached (and why)?
>>> Unfortunately I do not have RAM memory enough to install two (or three
>>> in some cases) virtual machines with Squid, so I would much appreciate
>>> your answers.
>>
>> This looks a lot like undergrad homework :P
>>
>> Notice that cache storage can be suppressed at any Squid on a wide
range
>> of criteria. So the answer to your question can change dependent on
what
>> you want to configure. The answers below are using the assumption that
>> all
>> proxies are storing everything cacheable which travels through them.
>>
>>>
>>> My answers:
>>> 1)
>>> when 1&2 doesn't have website requested:
>>> - 1 & 2 cached the website
>>
>> Yes. Everything going through #2 also goes through #1.
>>
>>>
>>> 2)
>>> when 1&2 doesn't have website requested:
>>> - 1 or 2 /it depends where the host is connected/ requests the website
>>> and cached it
>>>
>>> when 1 has the website requested, but host is connected to 2:
>>> - 2 requests website from 1, and cached /two servers cached after all/
>>>
>>> when 2 has the website requested, but host is connected to 1:
>>> - 1 requests website from 2, and cached /two servers cached after all/
>>>
>>
>> Yes.
>>
>> With condition that special request types such as CONNECT (and for some
>> older squid any dynamic web pages) are not passed to siblings when
direct
>> Internet access is available. These are usually non-cachable anyway so
>> have
>> little impact on the storage. They require admin config intervention to
>> use
>> the sibling.
>>
>>> 3)
>>> when 1&2&3 doesn't have website requested:
>>> - the website is cached 3 and 1 or 3 and 2 /it depends where the host
>>> is connected/
>>>
>>> when only 3 has the website
>>> - the website is cached 3 and 1 or 3 and 2 /it is copied from 3/
>>>
>>> when 1 or 2 has the website
>>> - the website is cached only 1 or only 2 or 1 and 2 or 2 and 1 /it
>>> depends where the host is connected/
>>
>> No. Simple join of scenarios (1) and (2).
>>
>> - proxy #3 caches everything. Because all traffic flows through it.
>>
>> - proxy #1 and #2 are exactly the same as scenario (2) with same
>> reasons.
>>
>> The fact that proxy #1 and #2 are connected to #3 instead of direct to
>> internet is not relevant to what gets cached.
>>
>>>
>>> 4) the same situation as in 2
>>
>> Yes.
>>
>> Scenario (1) and scenario (2) are the basic units of cache hierarchy
>> design. Same as with Internet route design. The complexity comes when
you
>> start limiting what requests can go where. Creating big loops, one-way
>> requests, non-caching, and peering routes.
>>
>> Amos
>>
Received on Wed Oct 20 2010 - 02:02:38 MDT

This archive was generated by hypermail 2.2.0 : Wed Oct 20 2010 - 12:00:03 MDT