[squid-users] Fwd: Squid configuration advise

[Yuri Voinov]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
 
Did your configure SSL Bump?

Ever since Squid 2.7 eternity. The world has changed and now the bulk of
the traffic is https. Which in general is not cached or must not cached
for many reasons.

And even in this case, Squid 3.3 too antique. I have updated to at least
version 3.5.


20.12.15 0:56, Jean Christophe Ventura пишет:
> Hi,
>
> I'm currently working to migrate RHEL5 2.7 Squid to RHEL7 3.3.
>
> I have migrated the config files to be 3.3 compliant (CIDR, remove of
> deprecated function,change cache from UFS to AUFS) without any change
> (cache mem, policy, smp)
>
> The new platform is a 4 node R610 (24 proc hyperthreading activate)
> with 48GB of RAM, only 143GB disk in RAID for OS and cache. Each node
> is connected to the network using 2x1Gbit bonding 2/3 level (some
> network port are available on the server).
>
> bandwidth allocated for Internet users 400Mbit
>
> The difference between the old plateform and the new one doesn't seem
> to be very fantastic :P
> I have read the mailing list history alot.
>
> Squid release:
> So i know 3.3 isn't anymore maintain but this infrastructure will be
> not maintain by myself and i don't think that people behind will do
> the update them self
> If a official repository exist, maybe this question will be reopen
> (from what i have read it's more some of you build packages from
> source and give them to people)
>
> Squid auth:
> It's transparent/basic auth only filtering some ip with acl.
>
> Squid bandwidth:
> Currently a squid node treat something like 30/50Mbit (information
> recovered using iftop)
> From previous viewed mail i think it's normal for a non-smp configuration
>
> Squid measure:
> [root at xxxx ~]# squidclient mgr:5min | grep 'client_http.requests'
> client_http.requests = 233.206612/sec
> other info
> Cache information for squid:
>         Hits as % of all requests:      5min: 6.8%, 60min: 7.1%
>         Hits as % of bytes sent:        5min: 4.7%, 60min: 4.4%
>         Memory hits as % of hit requests:       5min: 21.4%, 60min: 21.5%
>         Disk hits as % of hit requests: 5min: 34.7%, 60min: 30.8%
>         Storage Swap size:      9573016 KB
>         Storage Swap capacity:  91.3% used,  8.7% free
>         Storage Mem size:       519352 KB
>         Storage Mem capacity:   99.1% used,  0.9% free
>         Mean Object Size:       47.71 KB
>
> Now question and advise :
>
> This metrics seem too low for me. anyone of you agree ?
>
> 4 node x 50Mbit node= 200Mbit
> To treat the maxbandwidth (400Mbit) + the lost of one host i need to
> configure 4 thread by node.
> Is there any reason or brillant idea for more (i will have some core
> still available) ? calculation too empirical ?
>
> This url http://wiki.squid-cache.org/ConfigExamples/SmpCarpCluster
> seem to be a good start :P
> Using this method i can interconnect each proxy to share their cache
> (maybe using dedicated network port). Usefull or not ? may this
> increase the hit ratio ? if this idea is'nt stupid interconnet using
> the frontend only or directy to each ?
>
> For now i have :
> - 100GB of disk available for cache
> - 40GB   of RAM (let 8 for OS + squid disk cache related ram usage)
>
> 1 front with the RAM cache and 4 back with disk cache.
> AUFS or ROCK cache? mix of them ? 50% each ? maybe another rules ?
> (i think it's will be linked to the cache content but any advise or
> method is welcome)
>
> I can get more speed and/or space for disk cache using SAN, do you
> know if the data is sequential or random ?
>
> Any advise/rules to increase the hit ratio ? :)
> Any general advise/rules ?
>
> Thanks for your help
>
>
> Jean Christophe VENTURA
> _______________________________________________
> 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
 
iQEcBAEBCAAGBQJWdbHPAAoJENNXIZxhPexGizoIAM3CBf4DkJKybKh25ST4DBrz
2h790u7XgUpKrUYq+aZ4X1m55hNHsIgdOtsNpNXSZUtoYyCSRwM0nSYLHPm47Ov4
31nkO3/7hYfQoOkw514ZwGvI8YfkZJhBUZ8Nupev3HoRpbPMFf6XGaRji2LIFine
tne5JrOkQb2fkY0ev1FakPW8qcEzNtgDHC/2aoumxaq2MSKCPz34+j4W1QBYUDgy
ob7Dt7iT2bXb2pfLyXETY5K/7rznBLcMXcAaXcT6gxTOjGUpHZyq/QuZK4Db6WoD
45PwJelTkoSz8HFzajW6Du/5XItxejcLzvJq0X/wMzCvMFJaLzaL+FU49raDUl8=
=J9OH
-----END PGP SIGNATURE-----