Doi clienți descarcă același RPM prin Squid, dar a doua transferare ajunge totuși la o oglindă. Comparați adresele URL complete ale cererilor:

http://mirror-a.example.net/packages/tool-1.0.rpm
http://mirror-b.example.net/packages/tool-1.0.rpm

Numele fișierelor pachetului coincid; URI-urile țintă diferă. Cheile cache-ului HTTP includ cel puțin metoda cererii și URI-ul țintă, așa că sumele de control identice ale pachetului nu unesc automat aceste intrări.

Yum și DNF pot folosi un baseurl fix sau pot descoperi oglinzi prin mirrorlist și metalink. Prin urmare, instalări identice pot alege adrese URL de descărcare diferite.

Folosirea unei singure oglinzi aprobate oferă cererilor vizibile o identitate de cache consecventă. Păstrați aliniate căile depozitului, arhitectura și suita. Fixarea schimbă de asemenea disponibilitatea și comportamentul de selecție a oglinzilor, așa că faceți din ea o decizie de politică a depozitului.

Verificați dacă stocarea în cache a obiectelor este disponibilă

În interiorul unui tunel HTTPS CONNECT obișnuit, Squid nu poate vedea corpul răspunsului RPM pentru stocarea în cache HTTP. Un nume de gazdă de oglindă comun nu va schimba asta. Păstrați depozitele HTTPS criptate.

Pentru răspunsurile pe care Squid le poate stoca, reutilizarea depinde în continuare de prospețime, de directivele cererii și ale răspunsului și de politica locală de cache. Înregistrați adresa URL aleasă, dacă tranzacția a fost HTTP vizibil sau un tunel criptat, și rezultatul cache pentru a explica o ratare.

Articole similare