Når Squids autentiseringshjelpere blir en flaskehals

En proxyforespørsel kan vente på kontroll av innloggingsopplysninger før den når målet. Hvis uautentiserte forbindelser og allerede hurtigbufrede valideringer oppfører seg annerledes enn nye innlogginger, undersøk autentiseringsveien før du endrer nettverkets tidsgrenser.

Squid 6.13 kjører eksterne autentiseringshjelpere. En treg katalogtjeneste, uleselig kontofil, gjentatte hjelperavslutninger eller for få tilgjengelige hjelpere kan påvirke denne fasen på ulike måter.

Finn det faktiske begrensende trinnet

Se i cacheloggen etter oppstartsfeil, hjelperavslutninger og overbelastningsmeldinger. Hvis beskyttet lokal administrasjonsstatistikk finnes, undersøk hjelperaktiviteten der. Ikke eksponer et administrasjonsendepunkt offentlig bare for å få tellere.

Test backenden uavhengig med en testkonto. En hjelper som ikke fullfører én validering, trenger en funksjonsretting; flere kopier reparerer ikke en bane- eller rettighetsfeil.

Antall prosesser er ikke protokollsamtidighet

Et eksempel på en avgrenset prosesspool er:

auth_param basic children 16 startup=2 idle=2

Her har maksimalt prosessantall, startantall og ønsket ledig tilgjengelighet ulike formål. Verdiene er eksempler. Tilpass dem til målt etterspørsel og backendens tilkoblings- og ressursgrenser.

Det separate valget concurrency endrer protokollen mellom Squid og hjelperen. Det er ingen generell ytelsesbryter. Aktiver det bare når hjelperen uttrykkelig støtter nødvendige kanalidentifikatorer og samtidige forespørsler.

Hurtigbufring av innloggingsopplysninger påvirker også hvor ofte validering kreves. Kortere levetid med uendret hjelperpool kan øke arbeidet selv om nettlesertrafikken holder seg konstant.

Etter en endring, parse konfigurasjonen og sammenlign autentiseringsforsinkelse, feil og backendbelastning under representativ godkjent belastning. Vellykket parsing fastslår syntaks; det viser ikke at den nye poolen er raskere eller stor nok.