Kiedy pomocniki uwierzytelniania Squid stają się wąskim gardłem

Żądanie proxy może czekać na weryfikację danych logowania przed dotarciem do celu. Jeśli połączenia bez uwierzytelniania i walidacje już w cache zachowują się inaczej niż nowe logowania, sprawdź ścieżkę uwierzytelniania przed zmianą limitów czasu sieci.

Squid 6.13 uruchamia zewnętrzne pomocniki uwierzytelniania. Wolna usługa katalogowa, nieczytelny plik kont, powtarzające się zakończenia pomocników lub zbyt mało dostępnych pomocników mogą różnie wpływać na ten etap.

Znajdź rzeczywisty etap ograniczający

Sprawdź dziennik cache pod kątem błędów startu, zakończeń pomocników i komunikatów przeciążenia. Jeśli dostępne są chronione lokalne statystyki zarządzania, sprawdź tam aktywność pomocników. Nie udostępniaj publicznie punktu zarządzania tylko dla liczników.

Przetestuj backend niezależnie kontem testowym. Pomocnik, który nie kończy pojedynczej walidacji, wymaga naprawy działania; uruchomienie większej liczby kopii nie naprawia błędu ścieżki ani uprawnień.

Liczba procesów nie oznacza współbieżności protokołu

Przykład ograniczonej puli procesów:

auth_param basic children 16 startup=2 idle=2

Maksymalna liczba, liczba początkowa i pożądana dostępność bezczynnych procesów mają tu różne cele. Wartości są przykładowe. Dopasuj je do zmierzonego zapotrzebowania i limitów połączeń oraz zasobów backendu.

Oddzielna opcja concurrency zmienia protokół komunikacji Squid z pomocnikiem. Nie jest ogólnym przełącznikiem wydajności. Włącz ją tylko wtedy, gdy pomocnik jawnie obsługuje wymagane identyfikatory kanałów i jednoczesne żądania.

Cache danych logowania wpływa też na potrzebną częstotliwość walidacji. Skrócenie ważności bez zmiany puli pomocników może zwiększyć pracę nawet przy stałym ruchu przeglądania.

Po zmianie sparsuj konfigurację i porównaj opóźnienia uwierzytelniania, błędy i obciążenie backendu pod reprezentatywnym dozwolonym obciążeniem. Udane parsowanie potwierdza składnię, nie dowodzi większej szybkości ani wystarczającej wielkości puli.