Re: [squid-users] Maximum disk cache size per worker

From: Sokvantha Youk <sokvantha_at_gmail.com>
Date: Fri, 22 Mar 2013 16:18:39 +0700

On 3/22/2013 1:13 PM, Amos Jeffries wrote:
> On 22/03/2013 4:39 p.m., Alex Rousskov wrote:
>> On 03/21/2013 08:11 PM, Sokvantha YOUK wrote:
>>
>>> Thank you for your advice. If I want large files to be cached when it
>>> fist seen by worker, My config should change to first worker that see
>>> large file and cache it else left it over to remaining worker for rock
>>> store worker?
>> Your OS assigns workers to incoming connections. Squid does not control
>> that assignment. For the purposes of designing your storage, you may
>> assume that the next request goes to a random worker. Thus, each of your
>> workers must cache large files for files to be reliably cached.
>>
>>
>>> I don't want cached content to be duplicated
>>> among AUFS cache_dir and I want to use the advantage of rock store
>>> which can be shared within worker on SMP deployment.
>> The above is not yet possible using official code. Your options include:
>>
>> 1. Do not cache large files.
>>
>> 2. Cache large files in isolated per-worker ufs-based cache_dirs,
>> one ufs-based cache_dir per worker,
>> suffering from false misses and duplicates.
>> I believe somebody reported success with this approach. YMMV.
>>
>> 3. Cache large files in SMP-aware rock cache_dirs,
>> using unofficial experimental Large Rock branch
>> that does not limit the size of cached objects to 32KB:
>> http://wiki.squid-cache.org/Features/LargeRockStore
>>
>
> 4. Setup the SMP equivalent of a CARP peering hierarchy with the
> frontend workers using shared rock caches and the backend using UFS.
> This minimizes cache duplication. But in the current SMP code requires
> disabling loop detection (probably not a good thing) and some advanced
> configuration trickery.
> If you want to actually go down that path let me know and I'll put the
> details together.
>
> Amos
Dear Amos,

May you show me how to achieve at #4?

---
Regards,
Vantha
Received on Fri Mar 22 2013 - 09:19:18 MDT

This archive was generated by hypermail 2.2.0 : Fri Mar 22 2013 - 12:00:05 MDT