När Squids autentiseringshjälpare blir en flaskhals

En proxybegäran kan vänta på kontroll av inloggningsuppgifter innan den når destinationen. Om oautentiserade anslutningar och redan cachade valideringar beter sig annorlunda än nya inloggningar, undersök autentiseringsvägen innan nätverkstidsgränser ändras.

Squid 6.13 kör externa autentiseringshjälpare. En långsam katalogtjänst, oläsbar kontofil, upprepade hjälparavslut eller för få tillgängliga hjälpare kan påverka denna etapp på olika sätt.

Hitta det faktiskt begränsande steget

Se i cacheloggen efter startfel, hjälparavslut och överbelastningsmeddelanden. Om skyddad lokal administrationsstatistik finns, granska hjälparaktiviteten där. Exponera inte en administrationsändpunkt offentligt bara för att få räknare.

Testa backenden separat med ett testkonto. En hjälpare som inte klarar en enda validering behöver få funktionen rättad; fler kopior löser inte ett sökvägs- eller behörighetsfel.

Antalet processer är inte protokollets samtidighet

Ett exempel på en begränsad processpool är:

auth_param basic children 16 startup=2 idle=2

Här har maximalt processantal, startantal och önskad ledig tillgänglighet olika syften. Värdena är exempel. Anpassa dem efter uppmätt efterfrågan och backendens anslutnings- och resursgränser.

Det separata alternativet concurrency ändrar protokollet mellan Squid och hjälparen. Det är ingen allmän prestandaknapp. Aktivera det bara om hjälparen uttryckligen stöder de kanalidentifierare och samtidiga begäranden som krävs.

Cachning av inloggningsuppgifter påverkar också hur ofta validering behövs. Kortare giltighet med oförändrad hjälparpool kan öka arbetet även vid konstant webbtrafik.

Efter en ändring, tolka konfigurationen och jämför autentiseringsfördröjning, fel och backendbelastning under representativ godkänd belastning. Lyckad tolkning fastställer syntaxen; den visar inte att den nya poolen är snabbare eller tillräckligt stor.