Når autentiseringshjelparane til Squid vert ein flaskehals

Ein proxyførespurnad kan vente på kontroll av innloggingsopplysningar før han når målet. Viss uautentiserte samband og allereie mellomlagra valideringar oppfører seg annleis enn nye innloggingar, undersøk autentiseringsvegen før du endrar tidsgrenser i nettverket.

Squid 6.13 køyrer eksterne autentiseringshjelparar. Ei treg katalogteneste, ei uleseleg kontofil, gjentekne hjelparavslutningar eller for få tilgjengelege hjelparar kan påverke denne fasen ulikt.

Finn det faktiske avgrensande steget

Sjå i cacheloggen etter oppstartsfeil, hjelparavslutningar og overlastmeldingar. Viss verna lokal administrasjonsstatistikk finst, undersøk hjelparaktiviteten der. Ikkje eksponer eit administrasjonsendepunkt offentleg berre for å få teljarar.

Test baktenesta uavhengig med ein testkonto. Ein hjelpar som ikkje fullfører éi validering, treng retting av funksjonen; fleire kopiar reparerer ikkje ein bane- eller rettsfeil.

Talet på prosessar er ikkje protokollsamtidigheit

Eit døme på ein avgrensa prosesspool er:

auth_param basic children 16 startup=2 idle=2

Her har maksimalt prosesstal, starttal og ynskt ledig tilgjenge ulike føremål. Verdiane er døme. Tilpass dei til målt etterspurnad og tilkoplings- og ressursgrensene til baktenesta.

Det separate valet concurrency endrar protokollen mellom Squid og hjelparen. Det er ingen generell ytingsbrytar. Aktiver det berre når hjelparen uttrykkeleg støttar nødvendige kanalidentifikatorar og samtidige førespurnader.

Mellomlagring av innloggingsopplysningar påverkar òg kor ofte validering trengst. Kortare levetid med uendra hjelparpool kan auke arbeidet sjølv om nettlesartrafikken er konstant.

Etter ei endring, pars konfigurasjonen og samanlikn autentiseringsforseinking, feil og last på baktenesta under representativ godkjend last. Vellukka parsing slår fast syntaks; det viser ikkje at den nye poolen er raskare eller stor nok.