Калі Squid можа кэшаваць пакеты APT
Праверце транспарт HTTP, сховішча кэша, памер аб'екта і налады cache-control у APT, перш чым чакаць, што запыты пакетаў стануць трапленнямі Squid.
APT і aptitude могуць атрымліваць файлы рэпазіторыя праз HTTP. Squid можа кэшаваць прыдатны адказ HTTP; кліент не абавязаны быць вэб-браўзерам.
Для разгортвання Squid 6 або 7 праверце гэтыя ўваходныя даныя, калі кожная перадача пакета ўсё яшчэ дасягае крыніцы:
- Спампоўка выкарыстоўвае HTTP, або Squid іншым шляхам мае доступ да абмену HTTP. Адным тунэлем HTTPS CONNECT адказ пакета не робіцца даступным для кэшавання.
- У кэшы наладжана адпаведнае сховішча. Паспяховая перасылка не даказвае наяўнасць дыскавага кэша.
- Архіў змяшчаецца ў максімальны памер аб'екта адпаведнага каталога кэша. Малыя метаданыя і вялікі .deb могуць даць розныя вынікі.
- Запыт і адказ дазваляюць захоўванне і паўторнае выкарыстанне згодна з іх палітыкай cache-control.
APT прапануе Acquire::http::No-Cache, Max-Age і No-Store. No-Store можа перашкодзіць захаванню запытаных файлаў архіва. No-Cache патрабуе паўторнай праверкі перад паўторным выкарыстаннем захаванага адказу. Праверце эфектыўную канфігурацыю APT, а таксама палітыку Squid.
Параўнайце той самы поўны URL і праверце вынік кэша ў access.log. Розныя хасты люстэркаў, змененыя шляхі рэпазіторыя або лакальна закэшаваны пакет могуць азначаць, што дзве ўсталёўкі ніколі не запытваюць той самы сеткавы аб'ект.
Люстэрка рэпазіторыя падтрымлівае змест рэпазіторыя мэтанакіравана, а не спадзяецца толькі на паўторнае выкарыстанне кэша HTTP па запыце.