Files
zitadel/benchmark
3be21ccbf0 docs(perf): v4.17.1 results and harness fixes (#12651)
Publishes the v4.17.1 benchmark sweep and the harness fixes the sweep
uncovered.

## Results

All 11 published targets ran for 30 minutes each against a fixed
7-container deployment (vCPU 6 / 6 Gi, psql v17.4, US1 client and
server), at 600 VUs except where noted. Latencies are
`http_req_duration` over the test phase.

| target | VUs | iter/s | p50 | p95 | p99 | failed requests |
|:---|---:|---:|---:|---:|---:|:---|
| machine_pat_login | 600 | 3452 | 24.53ms | 872ms | 1.00s | 29 /
6,335,633 (0.00%) |
| user_info | 600 | 3217 | 29.32ms | 943ms | 1.13s | 66 / 5,800,788
(0.00%) |
| introspect | 600 | 2297 | 46.49ms | 1.16s | 1.36s | 1,400 / 4,159,863
(0.03%) |
| machine_jwt_profile_grant | 600 | 1076 | 85.34ms | 2.57s | 2.93s | 97
/ 1,986,156 (0.00%) |
| machine_client_credentials_login | 600 | 834 | 56.78ms | 1.74s | 2.42s
| 1,789 / 3,073,497 (0.05%) |
| add_session | 600 | 767 | 95.25ms | 3.53s | 4.15s | 1 / 1,416,546
(0.00%) |
| oidc_session | 600 | 326 | 77.47ms | 3.41s | 4.43s | 3 / 1,767,162
(0.00%) |
| otp_session | 600 | 84 | 47.80ms | 13.83s | 20.22s | 182 / 466,756
(0.03%) |
| password_session | 600 | 68 | 408.63ms | 20.00s | 24.05s | 1 / 253,280
(0.00%) |
| human_password_login | 600 | 49 | 146.67ms | 4.08s | 1m0s | 9,227 /
683,256 (1.35%) |
| manipulate_user | **200** | 19 | 304.58ms | 10.23s | 38.43s | 225 /
171,987 (0.13%) |

Against the goals:

- **#8352 is met.** `machine_jwt_profile_grant` reached **1076/s**
against the 1000/s goal, with p50 at 85ms.
- **#4424 is not met.** `human_password_login` runs at **49/s** against
a 1200/s goal.

The sweep ran with `improvedPerformance` enabled (`PROJECT_GRANT`,
`PROJECT`, `USER_GRANT`, `ORG_DOMAIN_VERIFIED`), captured from the
instance before the first target rather than assumed; the full flag set
is on every page.

## What the observability rows show

The containers were never the constraint. ZITADEL CPU sat at 9–50%
(p50), memory at 6–7% (p50, peaking at 16%) of 6 GiB, and instance count
was flat at 7 with no container startups in any window. Database CPU was
at **86–98% median on nine of eleven targets**. Any "ZITADEL achieves
N/s" figure that omits which resource ran out is true and misleading, so
the pages say.

The query breakdown then shows what the CPU numbers cannot: **advisory
lock wait is the single largest category of database time across the
sweep (91,857 s accumulated)**, ahead of event reads (64,805 s), event
push (26,411 s) and projection reads (14,625 s). The three locks are the
projection handler lock (`handler/v2/handler.go`), the eventstore read
barrier (`repository/sql/query.go`) and the shared lock every push takes
(`eventstore/v3/push.go`).

That is what sets the `flowchart outcome` on each page, and it is not
uniform:

- **Scale** on the seven targets where a resource genuinely ran out —
database CPU at 92–98% with 0% lock share.
- **Potential issues** on `human_password_login`, `password_session`,
`otp_session` and `manipulate_user`, where 45–74% of the top query time
is lock wait. `password_session` runs at 51% database CPU and 50%
container CPU and still only manages 68 iter/s; adding vCPU there buys
nothing.

Autovacuum is cleared as a contributor: 93.9% median DB CPU in buckets
containing a vacuum against 93.1% without, within noise. The new v4.17
eventstore autovacuum is barely triggered — `events2` is not in the top
twenty vacuumed tables.

## Harness fixes

Defects found during the sweep, all of which corrupted published numbers
or aborted runs:

1. **Colliding check names.** `updateHuman`, `lockUser` and `deleteUser`
all registered checks as `update user is status ok`, two of them
asserting `status === 201` against endpoints returning 200. k6
aggregates checks by name, so this produced a permanent, fictional 28%
failure rate. Each check now has its own name and accepts 2xx.
2. **User-creation read-after-write race**, in three variants, each
found after the previous fix. The read-back resolved `undefined` when
the projection was behind, surfacing much later as `Cannot read property
'0' of undefined`; then an unguarded `res.json()` turned every request
timeout into a killed iteration; then a *partial* read — a valid user
object with `loginNames` not yet projected — passed an `if (user)` guard
and failed identically. `readUserAfterCreate()` now guards status and
body before parsing, requires the field rather than the object, and
retries with backoff, rejecting with the user id and username.
3. **Metric cardinality.** Id-bearing URLs produced 800k+ time series
against k6's suggested 100k, driving k6 to 6.8 GB and an OOM mid-run.
All 16 such call sites now set a grouped `name` tag.
4. **`password_session` wrote its CSV to `otp_session`'s filename** in
the Makefile, silently overwriting the previous target's output.

The read-back race is not only a harness defect: at 600 VUs it measures
real load-induced projection lag, exceeding 25 s for login-name
projection and 100 s for the user projection, against instant reads on
an unloaded instance.

## Stable v2 user API

Four calls in `benchmark/src/user.ts` still went to `/v2beta/users` —
update, lock, delete and the machine read-back. They date from the
original load-test bootstrap in April 2024 (#7635), when the user
service was still v2beta, and were never moved when it was promoted;
they surfaced in this diff only because the read-after-write fix rewrote
the surrounding functions. All four are now on stable v2.

`updateHuman` is the one that changed shape: `PUT /v2beta/users/{id}` is
`UpdateHumanUser`, whose stable-v2 counterpart `PUT
/v2/users/human/{id}` is deprecated in the proto, so it now calls `PATCH
/v2/users/{id}` (`UpdateUser`) and `manipulate_user` nests the profile
under `human`. Both RPCs land on `command.ChangeUserHuman`, so the
measured work is unchanged. `lockUser`, `deleteUser` and the
`createMachine` read-back move over unchanged in method and payload.

No published result is affected: per-endpoint latencies come from custom
Trends, and `run-bench.sh` drops the `name` system tag, so no artefact
ever recorded a v2beta URL. The remaining `/management/v1` and
`/admin/v1` calls are left alone — migrating those changes which API
surface is benchmarked and would need a re-run.

## Timestamps

Pages reported `Test start` as a bare `HH:MM`, so a run could not be
correlated against monitoring the next day. Pages now carry the full UTC
date and time and a `Test end` row, both derived from the first and last
per-second row of `output.json`. `_template.mdx` is updated to match.

## Post-mortem

`benchmark/postmortems/2026-08-27-503-burst.md` records two bursts of
HTTP 503 `Service error -27` — an HTML page from the Google frontend,
not a ZITADEL error — on `manipulate_user` and `human_password_login`,
six hours apart. **The investigation is open**, and the note is explicit
about what is established (no container startups; the two bursts have
opposite server-side signatures), what is provisionally ruled out
(restart, panic), and what is not yet known. It is included because both
affected pages report the 503s as a separate population from the ZITADEL
failures beside them, and that split needs its evidence somewhere.

It also records two defects found by accident in the collected logs,
unrelated to the 503s: `sql: transaction has already been committed or
rolled back` (232 occurrences under load) and a missing i18n key,
`"unable to get user by id" not found in language "en"`.

## Notes for review

- **`manipulate_user` ran at 200 VUs, not 600, and the page says so.**
Throughput saturates near 100 VUs; at 600 the same target produced 4,283
failed requests for identical throughput against 225 at 200 VUs. Its
failure mode is degradation over sustained single-org churn —
per-operation p50 climbs 1.7x–6x between the first and last five minutes
of a run — not a concurrency threshold.
- **Two `Observed errors` rows are hand-corrected** and deliberately
differ from the generated text, on `manipulate_user` and
`human_password_login`. Both cases are one generated number covering two
unrelated failure populations; each page says it was corrected and why.
- Org deletion failing with a 500 (`V3-C8l3V`) after heavy user churn is
already tracked as #8510 and was hit repeatedly during cleanup.
- **The run/publish tooling is no longer part of this PR.** It moved to
a private repository, along with the cloud collection scripts, because
deployment identity does not belong here. What remains is the published
pages, the post-mortem findings and the harness fixes.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

---------

Co-authored-by: Claude Opus 5 (1M context) <[email protected]>
2026-09-01 19:12:37 +00:00
..
2025-10-08 10:27:02 +02:00
2025-10-08 10:27:02 +02:00

Benchmarks

This package contains code for benchmarking specific endpoints of the API using k6.

Prerequisite

  • npm
  • k6
  • go
  • xk6 (make sure ~/go/bin is in your ${PATH})
  • running the API

Structure

The use cases under tests are defined in src/use_cases. The implementation of ZITADEL resources and calls are located under src.

Execution

Env vars

  • VUS: Amount of parallel processes execute the test (default is 20)
  • DURATION: Defines how long the tests are executed (default is 200s)
  • ZITADEL_HOST: URL of ZITADEL (default is http://localhost:8080)
  • ADMIN_LOGIN_NAME: Loginanme of a human user with IAM_OWNER-role
  • ADMIN_PASSWORD: password of the human user
  • USER_AMOUNT: Number of users created during setup for list-users benchmarks (default is 2500)
  • SETUP_CONCURRENCY: Max in-flight user-create requests during list-users setup (default is 50). Large USER_AMOUNT with unbounded parallelism can exhaust ephemeral ports (can't assign requested address).

To setup the tests we use the credentials of management console and log in using an admin. The user must be able to create organizations and all resources inside organizations.

Test

Before you run the tests you need an initialized user. The tests don't implement the change password screen during login.

  • make human_password_login
    setup: creates human users
    test: uses the previously created humans to sign in using the login ui
  • make machine_pat_login
    setup: creates machines and a pat for each machine
    test: calls user info endpoint with the given pats
  • make machine_client_credentials_login
    setup: creates machines and a client credential secret for each machine
    test: calls token endpoint with the client_credentials grant type.
  • make user_info
    setup: creates human users and signs them in
    test: calls user info endpoint using the given humans
  • make manipulate_user
    test: creates a human, updates its profile, locks the user and then deletes it
  • make introspect
    setup: creates projects, one api per project, one key per api and generates the jwt from the given keys
    test: calls introspection endpoint using the given JWTs
  • make add_session
    setup: creates human users
    test: creates new sessions with user id check
  • make oidc_session
    setup: creates a service account to create the auth request and session.
    test: creates an auth request, a session and links the session to the auth request. Implementation of this flow.
  • make otp_session
    setup: creates 1 human user for each VU and adds OTP Email to it
    test: creates a session based on the login name of the user, sets the OTP Email challenge to the session and afterwards checks the OTP code
  • make password_session
    setup: creates 1 human user for each VU and adds OTP Email to it
    test: creates a session based on the login name of the user and checks for the password on a second step
  • make machine_jwt_profile_grant
    setup: generates private/public key, creates service accounts, adds a key
    test: creates a token and calls user info
  • make machine_jwt_profile_grant_single_user
    setup: generates private/public key, creates service account, adds a key
    test: creates a token and calls user info in parallel for the same user
  • make users_by_metadata_key
    setup: creates for half of the VUS a human user and a machine for the other half, adds 3 metadata to each user test: calls the list users endpoint and filters by a metadata key
  • make users_by_metadata_value
    setup: creates for half of the VUS a human user and a machine for the other half, adds 3 metadata to each user test: calls the list users endpoint and filters by a metadata value
  • make users_by_login_name
    setup: creates USER_AMOUNT human users (default 2500) in a new org, with SETUP_CONCURRENCY parallel creates (default 50)
    test: calls ListUsers the same way as login v2 (loginNameQuery with EQUALS_IGNORE_CASE, organizationIdQuery, limit: 2)
    note: to reproduce multi-second latency on the old query plan, use a large dataset, e.g. USER_AMOUNT=100000 VUS=10 DURATION=60s
  • make verify_all_user_grants_exists
    setup: creates 50 projects, 1 machine per VU test: creates a machine and grants all projects to the machine teardown: the organization is not removed to verify the data of the projections are correct. You can find additional information at the bottom of this file