Når Squids godkendelseshjælpere bliver en flaskehals

En proxyforespørgsel kan vente på kontrol af login, før den når destinationen. Hvis forbindelser uden godkendelse og allerede cachede valideringer opfører sig anderledes end nye login, så undersøg godkendelsesstien før netværkstidsgrænser ændres.

Squid 6.13 kører eksterne godkendelseshjælpere. En langsom katalogtjeneste, en ulæselig kontofil, gentagne hjælperstop eller for få tilgængelige hjælpere kan påvirke dette trin forskelligt.

Find det faktiske begrænsende trin

Se i cacheloggen efter opstartsfejl, hjælperstop og overbelastningsmeddelelser. Hvis beskyttede lokale administrationsstatistikker findes, undersøg godkendelseshjælpernes aktivitet der. Udstil ikke et administrationsendepunkt offentligt blot for at få tællere.

Test backenden uafhængigt med en testkonto. En hjælper, der ikke kan afslutte én validering, skal have rettet sin funktion; flere kopier reparerer ikke en sti- eller rettighedsfejl.

Procesantal er ikke protokolsamtidighed

Et eksempel på en afgrænset procespulje er:

auth_param basic children 16 startup=2 idle=2

Her har maksimalt procesantal, startantal og ønsket ledig tilgængelighed forskellige formål. Værdierne er eksempler. Tilpas dem til målt efterspørgsel og backendens forbindelses- og ressourcegrænser.

Den særskilte concurrency-indstilling ændrer protokollen mellem Squid og en hjælper. Det er ikke en generel ydelseskontakt. Aktivér den kun, når hjælperen udtrykkeligt støtter de krævede kanalidentifikatorer og samtidige forespørgsler.

Caching af legitimationsoplysninger påvirker også, hvor ofte validering er nødvendig. Kortere levetid med uændret hjælperpulje kan øge arbejdet, selv hvis browsertrafikken er konstant.

Efter en ændring, parse konfigurationen og sammenlign godkendelsesforsinkelse, fejl og backendbelastning under repræsentativ godkendt belastning. Vellykket parsing fastslår syntaks; den viser ikke, at den nye pulje er hurtigere eller stor nok.