Kiam Squid povas kaŝmemorigi APT-pakaĵojn
Kontrolu HTTP-transporton, kaŝmemoran konservadon, objekto-grandon kaj APT-agordojn pri cache-control antaŭ ol atendi, ke pakpetoj fariĝu trafoj de Squid.
APT kaj aptitude povas elpreni deponejajn dosierojn per HTTP. Squid povas kaŝmemorigi taŭgan HTTP-respondon; la kliento ne devas esti retumilo.
En Squid 6 aŭ 7 instalado, kontrolu tiujn enigojn kiam ĉiu paka translokigo ankoraŭ atingas la originon:
- La elŝuto uzas HTTP, aŭ Squid alie havas aliron al la HTTP-interŝanĝo. Nur HTTPS CONNECT-tunelo ne elmontras la pakrespondon por kaŝmemorigo.
- La kaŝmemoro havas taŭgan konservadon agorditan. Sukcesa plusendado ne pruvas, ke diskokaŝmemoro ekzistas.
- La arkivo konformas al la maksimuma objekto-grando de la koncerna kaŝmemora dosierujo. Malgrandaj metadatumoj kaj granda .deb povas havi malsamajn rezultojn.
- La peto kaj respondo permesas konservadon kaj reuzon laŭ sia cache-control-politiko.
APT elmontras Acquire::http::No-Cache, Max-Age kaj No-Store. No-Store povas malhelpi konservadon de petitaj arkivaj dosieroj. No-Cache postulas revalidigon antaŭ ol reuzi konservitan respondon. Kontrolu la efikan APT-agordon kaj ankaŭ la politikon de Squid.
Komparu la saman plenan URL-on kaj kontrolu la kaŝmemoran rezulton en access.log. Malsamaj spegulaj gastigantoj, ŝanĝitaj deponejaj vojoj aŭ loke kaŝmemorigita pakaĵo povas signifi, ke du instalaĵoj neniam petas la saman retobjekton.
Deponeja spegulo konservas deponejan enhavon intence anstataŭ fidi nur al postulbazita HTTP-kaŝmemora reuzo.