Rotacja serwerów lustrzanych zmienia to, co Squid może ponownie wykorzystać
Wyjaśnij, dlaczego identyczne pakiety RPM pobrane z różnych adresów URL serwerów lustrzanych mogą zajmować osobne wpisy pamięci podręcznej Squida.
Dwóch klientów pobiera ten sam RPM przez Squida, ale drugie przesłanie nadal trafia do serwera lustrzanego. Porównaj pełne adresy URL żądań:
http://mirror-a.example.net/packages/tool-1.0.rpm
http://mirror-b.example.net/packages/tool-1.0.rpmNazwy plików pakietu są zgodne; ich docelowe URI się różnią. Klucze pamięci podręcznej HTTP obejmują co najmniej metodę żądania i docelowy URI, więc zgodne sumy kontrolne pakietu nie łączą automatycznie tych wpisów.
Yum i DNF mogą używać stałego baseurl lub odkrywać serwery lustrzane przez mirrorlist i metalink. Dlatego identyczne instalacje mogą wybrać różne adresy URL pobierania.
Korzystanie z jednego zatwierdzonego serwera lustrzanego daje widocznym żądaniom spójną tożsamość pamięci podręcznej. Utrzymuj zgodność ścieżek repozytorium, architektury i zestawu. Przypinanie zmienia też dostępność i zachowanie wyboru serwera lustrzanego, więc uczyń je decyzją polityki repozytorium.
Sprawdź, czy buforowanie obiektów jest dostępne
Wewnątrz zwykłego tunelu HTTPS CONNECT Squid nie widzi treści odpowiedzi RPM na potrzeby buforowania HTTP. Wspólna nazwa hosta serwera lustrzanego tego nie zmieni. Utrzymuj repozytoria HTTPS zaszyfrowane.
W przypadku odpowiedzi, które Squid może buforować, ponowne wykorzystanie nadal zależy od świeżości, dyrektyw żądania i odpowiedzi oraz lokalnej polityki pamięci podręcznej. Zapisz wybrany adres URL, informację, czy transakcja była widocznym HTTP czy zaszyfrowanym tunelem, oraz jej wynik w pamięci podręcznej, aby wyjaśnić chybienie.