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
