There was an error while loading. Please reload this page.
Record the login-latency baseline from a controlled run [#1118] The Latency section carried a Pending marker, so the page named a characterization it did not hold and the release-over-release comparison it exists for had no first term. Nothing was measurable from it. Records the p50/p95/p99/max distribution for both scenarios and the concurrent throughput from the scheduled Performance baseline run on a GitHub-hosted runner, with the provenance that makes a later run comparable: runner label and image, processor count, SDK and runtime, plugin commit, harness parameters and the run URL. States what the harness excludes, so the numbers are not read as a deployment's login latency, and says the max column tracks runner noise rather than the plugin. The closing criterion list no longer says a controlled run is pending.
Replace the typographic dashes on every page 612 dashes across 22 of the 30 pages. No page ends a line with a space afterwards, and 566 dashes that would have started a Markdown list are escaped so the list does not appear. A wiki has no pull request and no gate, so the counts before and after are the evidence: the run is recorded in iderex/operations#861. Part of the fleet-wide pass in iderex/operations#860. Signed-off-by: Nils Lehnen <30603423+iderex@users.noreply.github.com>
Add the login-path performance and load baseline characterization (#742) New single-home page characterizing the login path's load behavior: the authorize-state store cap/sweep/concurrency, the per-client rate limiter, and the avatar deadline, each cited to its existing regression test (behavioral demonstration rather than a construction claim), linking to the Security Model design homes rather than duplicating them. Latency numbers are honestly marked pending a controlled CI/live run. Linked from the sidebar under How it works. Signed-off-by: iderex <30603423+iderex@users.noreply.github.com>