A tükrök rotációja megváltoztatja, mit tud újrahasznosítani a Squid
Magyarázza el, miért foglalhatnak el külön Squid gyorsítótár-bejegyzéseket a különböző tükör-URL-ekről letöltött azonos RPM-csomagok.
Két kliens ugyanazt az RPM-et tölti le a Squiden keresztül, de a második átvitel mégis elér egy tükröt. Hasonlítsa össze a kérések teljes URL-jeit:
http://mirror-a.example.net/packages/tool-1.0.rpm
http://mirror-b.example.net/packages/tool-1.0.rpmA csomag fájlnevei megegyeznek; a cél-URI-juk eltér. A HTTP gyorsítótár-kulcsok legalább a kérési metódust és a cél-URI-t tartalmazzák, ezért az egyező csomag-ellenőrzőösszegek nem vonják össze automatikusan ezeket a bejegyzéseket.
A Yum és a DNF használhat fix baseurl-et, vagy mirrorlist és metalink segítségével fedezhet fel tükröket. Ezért az azonos telepítések különböző letöltési URL-eket választhatnak.
Egyetlen jóváhagyott tükör használata egységes gyorsítótár-identitást ad a látható kéréseknek. Tartsa összhangban a tároló elérési útjait, az architektúrát és a csomagkészletet. A rögzítés a rendelkezésre állást és a tükörválasztás viselkedését is megváltoztatja, ezért tegye tárolószabályzati döntéssé.
Ellenőrizze, elérhető-e az objektum-gyorsítótárazás
Egy közönséges HTTPS CONNECT-alagútban a Squid nem látja az RPM-válasz törzsét a HTTP-gyorsítótárazáshoz. Egy közös tükör-gazdagépnév ezen nem változtat. Tartsa titkosítva a HTTPS-tárolókat.
Azoknál a válaszoknál, amelyeket a Squid gyorsítótárazhat, az újrafelhasználás továbbra is a frissességtől, a kérés- és válaszdirektíváktól, valamint a helyi gyorsítótár-szabályzattól függ. Jegyezze fel a kiválasztott URL-t, hogy a tranzakció látható HTTP vagy titkosított alagút volt-e, és a gyorsítótár-eredményét, hogy megmagyarázhassa a hibát.