Kad Squid var kešot APT pakotnes
Pārbaudiet HTTP pārvadi, kešatmiņas krātuvi, objekta izmēru un APT cache-control iestatījumus, pirms gaidāt, ka pakotņu pieprasījumi kļūs par Squid trāpījumiem.
APT un aptitude var iegūt repozitorija failus caur HTTP. Squid var kešot piemērotu HTTP atbildi; klientam nav jābūt tīmekļa pārlūkam.
Squid 6 vai 7 izvietojumā pārbaudiet šos ievades datus, kad katrs pakotnes pārsūtīšana joprojām sasniedz izcelsmi:
- Lejupielāde izmanto HTTP, vai arī Squid citādi ir piekļuve HTTP apmaiņai. Tikai HTTPS CONNECT tunelis neatklāj pakotnes atbildi kešošanai.
- Kešatmiņā ir konfigurēta piemērota krātuve. Veiksmīga pārsūtīšana nepierāda, ka pastāv diska kešatmiņa.
- Arhīvs iekļaujas attiecīgās kešatmiņas direktorijas maksimālajā objekta izmērā. Neliela metadatu apjoma un liela .deb rezultāti var atšķirties.
- Pieprasījums un atbilde atļauj uzglabāšanu un atkārtotu izmantošanu saskaņā ar to cache-control politiku.
APT piedāvā Acquire::http::No-Cache, Max-Age un No-Store. No-Store var novērst pieprasīto arhīva failu uzglabāšanu. No-Cache pieprasa atkārtotu validāciju pirms saglabātās atbildes atkārtotas izmantošanas. Pārbaudiet efektīvo APT konfigurāciju un arī Squid politiku.
Salīdziniet to pašu pilno URL un pārbaudiet kešatmiņas rezultātu failā access.log. Dažādi spoguļu resursdatori, mainīti repozitorija ceļi vai lokāli kešota pakotne var nozīmēt, ka divas instalācijas nekad nepieprasa vienu un to pašu tīkla objektu.
Repozitorija spogulis apzināti uztur repozitorija saturu, nevis paļaujas tikai uz pieprasījuma vadītu HTTP kešatmiņas atkārtotu izmantošanu.