Kailan makakapag-cache ang Squid ng mga APT package
Suriin ang transportasyong HTTP, imbakan ng cache, laki ng object at mga setting ng cache-control ng APT bago asahan na ang mga kahilingan ng package ay magiging Squid hit.
Ang APT at aptitude ay makakakuha ng mga file ng repositoryo sa pamamagitan ng HTTP. Ang Squid ay makakapag-cache ng karapat-dapat na tugon ng HTTP; ang kliyente ay hindi kailangang maging web browser.
Sa isang deployment ng Squid 6 o 7, suriin ang mga input na ito kapag ang bawat paglilipat ng package ay umaabot pa rin sa pinagmulan:
- Gumagamit ng HTTP ang pag-download, o ang Squid ay may access sa palitan ng HTTP sa ibang paraan. Ang isang HTTPS CONNECT tunnel lamang ay hindi naglalantad ng tugon ng package para sa cache.
- May angkop na imbakan na naka-configure ang cache. Ang matagumpay na pagpapasa ay hindi nagpapatunay na may disk cache.
- Kasya ang archive sa pinakamataas na laki ng object ng naaangkop na cache directory. Ang maliliit na metadata at malaking .deb ay maaaring magbigay ng magkaibang resulta.
- Pinapayagan ng kahilingan at tugon ang pag-imbak at muling paggamit ayon sa kanilang patakaran sa cache-control.
Inilalantad ng APT ang Acquire::http::No-Cache, Max-Age at No-Store. Maaaring pigilan ng No-Store ang pag-imbak ng mga hiniling na archive file. Humihingi ang No-Cache ng muling pagpapatunay bago muling gamitin ang naka-imbak na tugon. Suriin ang epektibong configuration ng APT gayundin ang patakaran ng Squid.
Ihambing ang parehong buong URL at suriin ang resulta ng cache sa access.log. Iba't ibang mirror host, binagong mga landas ng repositoryo o naka-cache na package sa lokal ay maaaring mangahulugan na ang dalawang install ay hindi kailanman humihingi ng parehong object ng network.
Ang mirror ng repositoryo ay sadyang nagpapanatili ng nilalaman ng repositoryo sa halip na umasa lamang sa muling paggamit ng HTTP cache kapag hinihingi.