Dear Amos, I am pretty sure love to go down to try SMP equivalent of a CARP peering. Please guide me. --- Regards, Vantha On Fri, Mar 22, 2013 at 1:13 PM, Amos Jeffries <squid3@xxxxxxxxxxxxx> 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 -- ---- Regards, Vantha
