Quan Squid pot fer memòria cau de paquets APT
Comproveu el transport HTTP, l'emmagatzematge de la memòria cau, la mida de l'objecte i la configuració de cache-control d'APT abans d'esperar que les peticions de paquets esdevinguin encerts de Squid.
APT i aptitude poden obtenir fitxers de repositori mitjançant HTTP. Squid pot fer memòria cau d'una resposta HTTP elegible; el client no ha de ser un navegador web.
En un desplegament de Squid 6 o 7, comproveu aquestes entrades quan cada transferència de paquet encara arriba a l'origen:
- La baixada utilitza HTTP, o Squid té accés d'una altra manera a l'intercanvi HTTP. Un túnel HTTPS CONNECT sol no exposa la resposta del paquet per a la memòria cau.
- La memòria cau té un emmagatzematge adequat configurat. Un reenviament correcte no demostra que existeixi una memòria cau en disc.
- L'arxiu cap a la mida màxima d'objecte del directori de memòria cau aplicable. Les metadades petites i un .deb gran poden tenir resultats diferents.
- La petició i la resposta permeten l'emmagatzematge i la reutilització segons la seva política de cache-control.
APT exposa Acquire::http::No-Cache, Max-Age i No-Store. No-Store pot impedir que s'emmagatzemin els fitxers d'arxiu sol·licitats. No-Cache demana una revalidació abans de reutilitzar una resposta emmagatzemada. Inspeccioneu la configuració efectiva d'APT així com la política de Squid.
Compareu el mateix URL complet i inspeccioneu el resultat de la memòria cau a access.log. Amfitrions de mirall diferents, rutes de repositori canviades o un paquet emmagatzemat localment poden significar que dues instal·lacions mai no demanen el mateix objecte de xarxa.
Un mirall de repositori manté el contingut del repositori deliberadament en lloc de dependre només de la reutilització de la memòria cau HTTP sota demanda.