Lasttesten für Login & Authentifizierungs-Spitzen

Login ist der Punkt, an dem Last zuerst weh tut. Ein Homepage-Treffer ist ein CDN-Lookup; ein Login ist ein bcrypt-Verify, ein DB-Round-Trip, ein Session-Write, oft ein OAuth-Tanz. Wenn ein Marketing-Push oder ein 9-Uhr-Schichtwechsel Zehntausende von Anmeldungen in dieselbe Minute kippt, ist das der Pfad, auf dem p95 zusammenbricht. Dieses Template skriptet ihn Ende-zu-Ende aus echtem Cloud-Egress.

bcrypt-Cost vs. Durchsatz

Ein einzelner bcrypt-Verify mit Cost 12 lauft ~250ms auf einem modernen x86-Core. Bei 1.000 Logins/Sek. sind das 250 CPU-Cores an Arbeit, bevor Sie die Datenbank uberhaupt anfassen. Cost 10 halbiert das; Cost 13 verdoppelt es. Rampen Sie Password-Grant-Traffic, bis Sie das Knie finden, dann dimensionieren Sie Auth-Replicas gegen den Cost-Faktor, den Sie tatsachlich ausliefern - nicht den aus der Config-Datei von 2019. Ziel: Login-p95 unter 500ms mit dem echten bcrypt-Cost im Loop.

OAuth2-Token-Exchange und Refresh-Rotation

Authorization-Code-Grants sind zwei Round-Trips: /authorize, dann /token. Unter Concurrency ist Refresh-Token-Rotation der Punkt, an dem die Korrektheit bricht - zwei Clients rennen um denselben Refresh-Token, der zweite bekommt ein 401, das SDK loggt den User stillschweigend aus. Feuern Sie Refresh-Requests aus mehreren VUs, die einen Token-Pool teilen, um diese Race-Condition sichtbar zu machen. Tracken Sie /token-p99 unter 1s und achten Sie auf 4xx-Cluster, die erst uber ~500 RPS auftauchen.

Session-Store-Hot-Keys

Wenn Sie Sessions mit Redis hinterlegen, konzentriert sich der Login-Write auf wenige Keys: Rate-Limit-Counter pro IP, Lockout-Counter pro Username, der Per-User-Session-List-Key. Hot-Key-Contention nagelt die CPU eines Shards fest, wahrend der Rest leer steht. Fahren Sie gegen den Cluster, beobachten Sie redis-cli --hotkeys parallel zum Test - Session-GET/SET-p95 sollte unter 5ms bleiben. Wenn es steigt, ist Ihr Sharding-Key falsch, nicht Ihre VU-Anzahl.

Account-Lockout wird zum DoS

Lockout-nach-N-fehlgeschlagenen-Versuchen ist unter Last ein Verstarker: Ein Angreifer mit einer Userlist sperrt jedes Konto mit jeweils einem fehlgeschlagenen Versuch. Bauen Sie ein kontrolliertes Fehlanmelde-Szenario ein, um zu messen, wie sich der Lockout-Zustand uber Ihr verteiltes Lock-Backend ausbreitet, und bestatigen Sie, dass legitime Nutzer noch durchkommen, wahrend schlechter Traffic abgewiesen wird. Per-IP-, Per-Account- und Per-Tenant-Rate-Limits tunen sich jeweils separat.

Password-Spray und geteilte Egress-IPs

VUs verteilt auf eine Handvoll Egress-IPs sehen fur Ihre WAF exakt aus wie Password-Spray. Wenn der Test im Ramp-Schritt eins den Rate-Limiter ausloste, testen Sie Ihre WAF, nicht Ihren Auth-Service. Streuen Sie VUs uber 26+ Cloud-Regionen, damit das Per-IP-Budget realistisch ist. Captcha-Injection-Schwellen gehoren ins Skript - wenn echte User bei 5 Fehlversuchen Captcha treffen, sollte Ihr Skript es am selben Punkt treffen.

JWT-Verify und SAML-SLO

Nach dem Login verifiziert jeder Request ein JWT. RS256 ist ~10x die CPU von HS256 und zeigt sich im Steady State, nicht in der Spitze. SAML-Single-Logout-Endpoints stauen sich unter parallelen IdP-initiierten Logouts und werden so gut wie nie gebenchmarkt. Decken Sie beides ab: eine Post-Login-Warm-Phase, die JWT-Verify trainiert, plus einen SLO-Sturm fur SAML.

Ausfuhren

Importieren Sie das Szenario, zeigen Sie auf Staging, rampen Sie von 100 auf Peak-Concurrent-Anmeldungen uber 10 Minuten. Nutzen Sie JMeter-Modus mit einem aufgezeichneten Flow oder k6-Modus, um den OAuth-Handshake direkt zu skripten. Verdrahten Sie in CI, damit jedes Auth-Service-Deploy die Spitze fahrt, bevor es promoted wird.