Performance and Load Baseline

Performance and load baseline

This page characterizes the login path's behavior under load and concurrency - the RC-readiness question of #742. The login path carries three load-oriented controls; each is pinned by regression tests that double as the behavioral demonstration, and a machine-independent latency baseline is recorded separately (see Latency).

The load controls and their proven behavior

Authorize-state store: cap and sweep

The OpenID authorize-state store bounds outstanding challenges at a global cap (OidcStateStore.DefaultMaxEntries = 100,000) and reclaims expired entries with a sweep throttled to at most once per minute - design in Security Model § In-flight login capacity. The behavior under a challenge flood is a regression test, not a construction claim (SSO-Auth.Tests/Oidc/OidcStateStoreTests):

• At the cap a fresh challenge is refused, never an in-flight state evicted - TryAdd_AtCap_RefusesANewKeyAndKeepsTheInFlightState, TryAdd_DistinctKeys_FillToGlobalCap_ThenRefuseNotEvict. The refusal surfaces to the user as the clean Could not start login; please retry response (a 500), never an out-of-memory.
• Per-client isolation - a flood from one client key cannot refuse a different key's challenge (TryAdd_FloodFromOneKey_DoesNotRefuseADifferentKey); each client is additionally held to a 1% share of the cap (up to 1,000 concurrent in-flight logins per client).
• The capacity warning is throttled to once per interval, so a flood cannot amplify into unbounded logging (TryAdd_Refused_SignalsTheCapacityWarningOncePerInterval).
• Under concurrency the store stays bounded and the sweep never corrupts it - TryAdd_UnderContention_StaysBoundedAndRejectsSome, PruneExpired_ConcurrentWithAdds_DoesNotThrowAndKeepsFreshEntries.
• The sweep runs at most once per minute, keeping its O(n) scan off the anonymous hot path (PruneExpired_WithinTheInterval_IsThrottled_AndTheUnsweptEntryIsStillRejected).

Per-client rate limiting

The edge rate limiter throttles a hammering client with a 429 + Retry-After while a normal multi-stage login (including an MFA retry) never trips it - design in Security Model § Rate limiting. Pinned by the SsoRateLimiter and PerClientBudgetLimiter test suites, with the 429/Retry-After emission covered through the login status mapper.

Avatar fetch deadline

The optional avatar fetch is bounded by a deadline (and the SSRF allow-list) so a slow or hostile IdP-hosted image cannot stall the login; the AvatarService tests pin the deadline and abort behavior.

Latency

A machine-independent latency baseline (challenge + callback round-trip, nominal and concurrent) is a characterization, not a CI gate. It must be captured on a controlled runner (CI, or a representative server) rather than a developer laptop so the numbers are comparable release-over-release. The behavioral guarantees above hold regardless of the absolute latency.

Pending: record the measured numbers here after a controlled run.

Mapping to #742

• Cap / sweep / in-flight under concurrency (acceptance criterion 2) → the OidcStateStore regression tests above.
• Rate-limit throttle vs. a normal login (criterion 3) → the rate-limiter test suites above.
• Baseline latency numbers (criterion 1) → pending a controlled run (Latency).