Kiedy Squid może buforować pakiety APT
Sprawdź transport HTTP, magazyn pamięci podręcznej, rozmiar obiektu i ustawienia cache-control APT, zanim zaczniesz oczekiwać, że żądania pakietów staną się trafieniami Squida.
APT i aptitude mogą pobierać pliki repozytorium przez HTTP. Squid może buforować kwalifikującą się odpowiedź HTTP; klient nie musi być przeglądarką internetową.
W instalacji Squida 6 lub 7 sprawdź te dane wejściowe, gdy każde przesyłanie pakietu nadal dociera do źródła:
- Pobieranie używa HTTP albo Squid ma inny dostęp do wymiany HTTP. Sam tunel HTTPS CONNECT nie udostępnia odpowiedzi pakietu do buforowania.
- Pamięć podręczna ma skonfigurowany odpowiedni magazyn. Udane przekazanie nie dowodzi, że istnieje pamięć podręczna na dysku.
- Archiwum mieści się w maksymalnym rozmiarze obiektu odpowiedniego katalogu pamięci podręcznej. Małe metadane i duży plik .deb mogą dać różne wyniki.
- Żądanie i odpowiedź pozwalają na przechowywanie i ponowne użycie zgodnie z ich polityką cache-control.
APT udostępnia Acquire::http::No-Cache, Max-Age i No-Store. No-Store może uniemożliwić przechowywanie żądanych plików archiwum. No-Cache wymaga ponownej walidacji przed ponownym użyciem przechowywanej odpowiedzi. Sprawdź efektywną konfigurację APT oraz politykę Squida.
Porównaj ten sam pełny URL i sprawdź wynik pamięci podręcznej w access.log. Różne hosty luster, zmienione ścieżki repozytorium lub pakiet buforowany lokalnie mogą oznaczać, że dwie instalacje nigdy nie żądają tego samego obiektu sieciowego.
Lustro repozytorium celowo utrzymuje zawartość repozytorium, zamiast polegać wyłącznie na ponownym użyciu pamięci podręcznej HTTP na żądanie.