<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
-----BEGIN PGP SIGNED MESSAGE----- <br>
Hash: SHA256 <br>
<br>
My best result I can achieve this day with 3.5.12 is:<br>
<br>
<a class="moz-txt-link-freetext" href="http://i.imgur.com/Lm6MkwH.png">http://i.imgur.com/Lm6MkwH.png</a><br>
<br>
Maximum hit level is 50-55%. With VERY complex configuration.<br>
<br>
With old good 3.4.14 I achieved cache hit over 86%, but this is in
the past.<br>
<br>
20.12.15 1:59, Jean Christophe Ventura пишет:<br>
<span style="white-space: pre;">> Reading the mailing list i know
that sslbump is the question to get a more<br>
> usefull hit.<br>
><br>
> But this proxy infrastructure isn't acting as my company
proxy but isp<br>
> proxy for the company client and i cann't go to this way
without some guy<br>
> like lawers/security guys :)<br>
><br>
> I know there is no magic button to get the full internet at
home ;) but at<br>
> least my job with this project constraint is to get the best
i can :)<br>
><br>
> 2015-12-19 20:51 GMT+01:00 Yuri Voinov
<a class="moz-txt-link-rfc2396E" href="mailto:yvoinov@gmail.com"><yvoinov@gmail.com></a>:<br>
><br>
>><br>
> I'm sorry that upset. :)<br>
><br>
> 20.12.15 0:56, Jean Christophe Ventura пишет:<br>
> >>> Hi,<br>
> >>><br>
> >>> I'm currently working to migrate RHEL5 2.7 Squid
to RHEL7 3.3.<br>
> >>><br>
> >>> I have migrated the config files to be 3.3
compliant (CIDR, remove of<br>
> >>> deprecated function,change cache from UFS to
AUFS) without any change<br>
> >>> (cache mem, policy, smp)<br>
> >>><br>
> >>> The new platform is a 4 node R610 (24 proc
hyperthreading activate)<br>
> >>> with 48GB of RAM, only 143GB disk in RAID for OS
and cache. Each node<br>
> >>> is connected to the network using 2x1Gbit
bonding 2/3 level (some<br>
> >>> network port are available on the server).<br>
> >>><br>
> >>> bandwidth allocated for Internet users 400Mbit<br>
> >>><br>
> >>> The difference between the old plateform and the
new one doesn't seem<br>
> >>> to be very fantastic :P<br>
> >>> I have read the mailing list history alot.<br>
> >>><br>
> >>> Squid release:<br>
> >>> So i know 3.3 isn't anymore maintain but this
infrastructure will be<br>
> >>> not maintain by myself and i don't think that
people behind will do<br>
> >>> the update them self<br>
> >>> If a official repository exist, maybe this
question will be reopen<br>
> >>> (from what i have read it's more some of you
build packages from<br>
> >>> source and give them to people)<br>
> >>><br>
> >>> Squid auth:<br>
> >>> It's transparent/basic auth only filtering some
ip with acl.<br>
> >>><br>
> >>> Squid bandwidth:<br>
> >>> Currently a squid node treat something like
30/50Mbit (information<br>
> >>> recovered using iftop)<br>
> >>> From previous viewed mail i think it's normal
for a non-smp configuration<br>
> >>><br>
> >>> Squid measure:<br>
> >>> [root@xxxx ~]# squidclient mgr:5min | grep
'client_http.requests'<br>
> >>> client_http.requests = 233.206612/sec<br>
> >>> other info<br>
> >>> Cache information for squid:<br>
> >>> Hits as % of all requests: 5min:
6.8%, 60min: 7.1%<br>
> >>> Hits as % of bytes sent: 5min:
4.7%, 60min: 4.4%<br>
> >>> Memory hits as % of hit requests:
5min: 21.4%, 60min: 21.5%<br>
> >>> Disk hits as % of hit requests: 5min:
34.7%, 60min: 30.8%<br>
> >>> Storage Swap size: 9573016 KB<br>
> >>> Storage Swap capacity: 91.3% used,
8.7% free<br>
> >>> Storage Mem size: 519352 KB<br>
> >>> Storage Mem capacity: 99.1% used,
0.9% free<br>
> >>> Mean Object Size: 47.71 KB<br>
> >>><br>
> >>> Now question and advise :<br>
> >>><br>
> >>> This metrics seem too low for me. anyone of you
agree ?<br>
> >>><br>
> >>> 4 node x 50Mbit node= 200Mbit<br>
> >>> To treat the maxbandwidth (400Mbit) + the lost
of one host i need to<br>
> >>> configure 4 thread by node.<br>
> >>> Is there any reason or brillant idea for more (i
will have some core<br>
> >>> still available) ? calculation too empirical ?<br>
> >>><br>
> >>> This url
<a class="moz-txt-link-freetext" href="http://wiki.squid-cache.org/ConfigExamples/SmpCarpCluster">http://wiki.squid-cache.org/ConfigExamples/SmpCarpCluster</a><br>
> >>> seem to be a good start :P<br>
> >>> Using this method i can interconnect each proxy
to share their cache<br>
> >>> (maybe using dedicated network port). Usefull or
not ? may this<br>
> >>> increase the hit ratio ? if this idea is'nt
stupid interconnet using<br>
> >>> the frontend only or directy to each ?<br>
> >>><br>
> >>> For now i have :<br>
> >>> - 100GB of disk available for cache<br>
> >>> - 40GB of RAM (let 8 for OS + squid disk cache
related ram usage)<br>
> >>><br>
> >>> 1 front with the RAM cache and 4 back with disk
cache.<br>
> >>> AUFS or ROCK cache? mix of them ? 50% each ?
maybe another rules ?<br>
> >>> (i think it's will be linked to the cache
content but any advise or<br>
> >>> method is welcome)<br>
> >>><br>
> >>> I can get more speed and/or space for disk cache
using SAN, do you<br>
> >>> know if the data is sequential or random ?<br>
> >>><br>
> >>> Any advise/rules to increase the hit ratio ? :)<br>
> >>> Any general advise/rules ?<br>
> >>><br>
> >>> Thanks for your help<br>
> >>><br>
> >>><br>
> >>> Jean Christophe VENTURA<br>
> >>> _______________________________________________<br>
> >>> squid-users mailing list<br>
> >>> <a class="moz-txt-link-abbreviated" href="mailto:squid-users@lists.squid-cache.org">squid-users@lists.squid-cache.org</a><br>
> >>>
<a class="moz-txt-link-freetext" href="http://lists.squid-cache.org/listinfo/squid-users">http://lists.squid-cache.org/listinfo/squid-users</a><br>
><br>
>><br>
>> _______________________________________________<br>
>> squid-users mailing list<br>
>> <a class="moz-txt-link-abbreviated" href="mailto:squid-users@lists.squid-cache.org">squid-users@lists.squid-cache.org</a><br>
>> <a class="moz-txt-link-freetext" href="http://lists.squid-cache.org/listinfo/squid-users">http://lists.squid-cache.org/listinfo/squid-users</a><br>
>><br>
></span><br>
<br>
-----BEGIN PGP SIGNATURE-----
<br>
Version: GnuPG v2
<br>
<br>
iQEcBAEBCAAGBQJWdbe9AAoJENNXIZxhPexGnnMIAJCpFZJVppW4auNDES0Z1SOX
<br>
Essle25MJ1yKh3BkkkRhJa4pJjCa/9fYrnTwOTQ3IFDvuILbesjxxtIBkbBjEvzi
<br>
Ka5oHoKokN8/9kMwDjBUYUua8aHqDhPaQ197bD6HZTzX5nzq3DU3Wnoa8jkyLSX9
<br>
LJiNbdYhvbJN4CH3ui8Q0JOKlTbYM43Jc0mTfW/K3Rv2Yv68EzYTwx7OeniXyMNO
<br>
SitP72nntqntAOL48s9stG9vr3j0bPZRu/ejcW4LoTbj719nuhSYeB7a0mTgStZp
<br>
Y1Elcm61cTefFgG9Cvggnr8mkp1AionnZHffPmkaZDzuParz6UMsHcCKmZFH4BE=
<br>
=y1hW
<br>
-----END PGP SIGNATURE-----
<br>
<br>
</body>
</html>