[squid-users] Large rock supporting with stable squid version

Amos Jeffries squid3 at treenet.co.nz
Wed Oct 29 02:59:59 UTC 2014


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 29/10/2014 9:46 a.m., Ahmed Allzaeem wrote:
> Hi Amos , thank you.
> 
> I just wanted to explain something
> 
> Now , im okay without SMP , I can save bandwidth and its fine...but
> cores are not balanced and that may lead some cpu cores reach 100
> %
> 
> But...... I need to use SMP with large rock to save bandwidth ....
> now it works fine ...but no saving !! Im using 3.4.7 stable
> 
> What I need is , Someone used 3.head and found a result of saving
> bandwith.....as an example wt max cache size and mem size allow in
> large rock ?
> 


How are you testing for savings?
 - things as simple as pressing the browser refresh button can screw
up the results. "Refresh/reload" button sends a cache-control forcing
a MISS instead of HIT.

How are you measuring for savings?

Does your cachemgr "info" report byte-HIT ratio show greater than 0.0 ?
 - if so you are saving by that amount.


> 
> That wt I need .... I need a fast browsing squid  that can save my
> bandwidth.

Understood. Lets get you there.

> Amos , can u guide me with a 3.head verison you used with large
> rock and gave you thr best results of saving bandwidth ???
> 

I have not had any need to tune rock cache particularly. It just
worked for me.

Amos


> regards
> 
> -----Original Message----- From: squid-users
> [mailto:squid-users-bounces at lists.squid-cache.org] On Behalf Of
> Amos Jeffries Sent: Monday, October 27, 2014 5:53 PM To:
> squid-users at lists.squid-cache.org Subject: Re: [squid-users] Large
> rock supporting with stable squid version
> 
> On 25/10/2014 2:09 a.m., Ahmed Allzaeem wrote:
>> Hi
> 
>> I want to ask about Large rock supporting.
> 
>> In large rock supporting wts the max size for disk store ? and
>> max size of ram store?
> 
> The disk store limit depends on HDD/SSD space available. That goes
> for all cache_dir types.
> 
> 
> What do you mean by "ram store" ?
> 
> IIRC, rock storage does away with the split memory/disk "slices" 
> which were used in COSS. So there is no tricky management of how
> many slices are in memory and swapping in/out.
> 
> Squid has a RAM store (cache_mem) which is not particularly related
> to Rock storage. You need to tune that cache_mem size around how
> much RAM is used for all cache_dir existing, and active transaction
> needs. Nobody can tell you the answer since the administrative
> "test, measure, tune" process is the only way to find it.
> 
> 
> 
>> I need someone tried large rock with squid 3.head version and
>> have seen a stability , I used last time squid3.head but it
>> hanged after sometime
> 
> 
> Details required. "hangs after some time" and "it" are very vague.
> 
> 
>> I need  a help with a squid large rock  best practice.
> 
> 
> The feature is still in beta. As an early adopter you are one of
> the people whose feedback will define what the best practice in
> future will be.
> 
> Despite being *capable* of large object storage rock is optimal for
> small objects. UFS/AUFS/diskd cache types are optimal for large
> objects - except no SMP sharing there yet which is just annoying.
> 
> For now the regular best practice for cache_dir in general applies.
> To ensure you have enough RAM for cache index (10-15MB er GB of
> cached data) not to cause memory swapping, to ensure you do not
> exceded available disk space, etc. etc.
> 
> Amos
> 
> _______________________________________________ squid-users mailing
> list squid-users at lists.squid-cache.org 
> http://lists.squid-cache.org/listinfo/squid-users
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBAgAGBQJUUFgvAAoJELJo5wb/XPRj8coIAK81FHh7477B9F9UTNUj6TuY
mmi0OaQBLTgW7uyb3VZmyqjEqbZCaPva0du/JM1bpT2QudUsodrzQSvNyXPcBHxa
ne+GUfJAGnlf7bbeLuaL4uQjh5VagzwmzHffGxr/J7ekvBIduDzPfMwsWvJkVPct
rkgZ32UMayU8q3QwLV1MlG7K6MljfZUkeT0mKdoxGiNisnLlb4fRQ87tnaGCbiPR
50BdNpjQPvZjrBuAGWw9w2s8UNSpjNK8JQUsH++joonZ45K2kA4nTZGTweEnXVcm
31Q1tswg6OMLOKLV0uGM5zqSf0fxEp1vL0WVfuDEqe4rjPzWOyaNrkvTPLXvMX4=
=ZW9I
-----END PGP SIGNATURE-----


More information about the squid-users mailing list