Kada Squid može keširati APT pakete
Provjerite HTTP prijenos, keš pohranu, veličinu objekta i APT postavke cache-controla prije nego što očekujete da zahtjevi za paketima postanu Squid pogoci.
APT i aptitude mogu dohvatiti datoteke repozitorija putem HTTP-a. Squid može keširati prihvatljiv HTTP odgovor; klijent ne mora biti web preglednik.
U implementaciji Squida 6 ili 7 provjerite ove ulaze kada svaki prijenos paketa još uvijek stiže do izvora:
- Preuzimanje koristi HTTP ili Squid na drugi način ima pristup HTTP razmjeni. Samo HTTPS CONNECT tunel ne izlaže odgovor paketa za keširanje.
- Keš ima konfiguriran odgovarajući prostor. Uspješno prosljeđivanje ne dokazuje da disk keš postoji.
- Arhiva se uklapa u najveću veličinu objekta primjenjivog keš direktorija. Mali metapodaci i veliki .deb mogu dati različite rezultate.
- Zahtjev i odgovor dopuštaju pohranu i ponovnu upotrebu prema svojoj cache-control politici.
APT izlaže Acquire::http::No-Cache, Max-Age i No-Store. No-Store može spriječiti pohranu zatraženih arhivskih datoteka. No-Cache traži ponovnu provjeru prije ponovne upotrebe pohranjenog odgovora. Provjerite efektivnu APT konfiguraciju kao i Squid politiku.
Usporedite isti potpuni URL i provjerite rezultat keša u access.log. Različiti hostovi zrcala, promijenjene putanje repozitorija ili lokalno keširan paket mogu značiti da dvije instalacije nikada ne traže isti mrežni objekt.
Zrcalo repozitorija održava sadržaj repozitorija namjerno, umjesto da se oslanja samo na ponovnu upotrebu HTTP keša na zahtjev.