human password login benchmark of zitadel v4.17.1
Benchmark results of the v4.17.1 release of Zitadel.
Performance test results
| Metric | Value |
|---|---|
| Baseline | none |
| Purpose | Test current performance |
| Test start | 2026-08-27 19:24:36 UTC |
| Test end | 2026-08-27 19:54:52 UTC |
| Test duration | 30min |
| Executed test | human_password_login |
| k6 version | v2.1.0 |
| VUs | 600 |
| Client location | US1 |
| ZITADEL location | US1 |
| ZITADEL container specification | vCPU: 6 Memory: 6 Gi Container min scale: 7 Container max scale: 7 |
| ZITADEL Version | v4.17.1 |
| ZITADEL Settings | Eventstore autovacuum (new in v4.17): Enabled: true VacuumThreshold: 1000000 AnalyzeThreshold: 1000000 Tuned for the ~4,000 events/s expected during the benchmark, per the tuning guide. |
| ZITADEL feature flags | Enabled: loginDefaultOrg (instance), oidcTokenExchange (system), enableBackChannelLogout (system), consoleUseV2UserApi (instance) improvedPerformance (instance): IMPROVED_PERFORMANCE_PROJECT_GRANT, IMPROVED_PERFORMANCE_PROJECT, IMPROVED_PERFORMANCE_USER_GRANT, IMPROVED_PERFORMANCE_ORG_DOMAIN_VERIFIED Disabled: loginV2 (explicitly false at instance), userSchema, debugOidcParentError, oidcSingleV1SessionTermination, permissionCheckV2 Captured from the instance before the run (sequence 7, set 2026-08-27 13:35:31 UTC); the same capture covers manipulate_user at 13:41 and the rest of the sweep from 14:56, so all eleven targets ran the same configuration.This restores like-for-like comparison with the v4 pages, which ran five improvedPerformance options. The fifth, IMPROVED_PERFORMANCE_ORG_BY_ID, is reserved in the proto and no longer exists. |
| Database | type: psql version: v17.4 |
| Database location | US1 |
| Database specification | vCPU: 8 memory: 32Gib |
| ZITADEL metrics during test | CPU: p50 48%, p99 60% (peak 64%) Memory: p50 6%, peak 16% Instances: 7 (constant), no container startups recorded Server-side: 338 req/s, latency p50 207ms / p95 4.9s / p99 32.9s |
| Observed errors | 9,227 of 683,256 requests failed (1.35%). Corrected by hand from the generated row, which reported these as one population; the status breakdown shows two with different causes and different shapes. (1) 8,178 request timeouts (1.20%), sustained across the whole run — not a burst: they run from 19:26 to 19:54 at a steady 125–360 per minute, with no onset and no recovery. This is ZITADEL under 600 VUs on this target and is the number to read. (2) 1,044 HTTP 503 platform errors, confined to 19:37–19:44 — Service error -27, an HTML page from the Google frontend rather than a ZITADEL JSON error, in the same bounded-burst shape seen on manipulate_user at 13:43 the same day and pending the same GCP post-mortem (see benchmark/postmortems/2026-08-27-503-burst.md). Plus 4x HTTP 502 and 1x connection reset, scattered singles. 9,093 of 1,007,953 checks failed (0.90%): login name status ok (8,345), authorize status ok (333), token status ok (138), password status ok (137), userinfo status ok (119), password callback (21). The failed checks track the timeouts rather than the 503 burst. |
| Top 3 most expensive database queries | 1: Projection handler advisory lock, one per projection per instance — lock wait, not query work (17,902 s) 2: Eventstore read barrier: advisory lock + unlock on events2 — lock wait (8,920 s)3: Query events by instance_id, aggregate_types, event_types, position (paged) (3,810 s) Ranked by total accumulated execution time summed across concurrent sessions (Cloud SQL Query Insights) — not CPU time; it can exceed the wall-clock window. |
| Database metrics during test | CPU: 87% median, 90% peak Memory: 40% Connections: 46 Transactions: 12,351/s IOPS: read 0, write 711 CPU-saturated — the bottleneck for this target. |
| k6 Iterations per second | 49 |
| k6 output | output |
| flowchart outcome | Potential issues. Not resource-bound: database CPU 87%, ZITADEL CPU 48%, yet 86% of the top-5 query time is advisory lock wait — predominantly the projection handler lock, which serialises this workload. Additional vCPU will not help. Logged as an issue rather than blocking further scale testing. The run also contains a 1,044-request platform 503 burst (19:37-19:44) under separate investigation in benchmark/postmortems/2026-08-27-503-burst.md; it does not affect this verdict. |
Endpoint latencies
k6 output
█ TOTAL RESULTS
checks_total.......: 1007953 542.050139/s
checks_succeeded...: 99.09% 998860 out of 1007953
checks_failed......: 0.90% 9093 out of 1007953
✓ user defined
✗ authorize status ok
↳ 99% — ✓ 90339 / ✗ 333
✗ login name status ok
↳ 90% — ✓ 81994 / ✗ 8345
✓ login shows password page
✗ password status ok
↳ 99% — ✓ 81702 / ✗ 137
✗ password callback
↳ 99% — ✓ 81681 / ✗ 21
✓ code set
✗ token status ok
↳ 99% — ✓ 81543 / ✗ 138
✓ access token created
✓ id token created
✓ info created
✓ org created
✓ create user is status ok
✓ openid configuration
✗ userinfo status ok
↳ 99% — ✓ 81423 / ✗ 119
✓ org removed
CUSTOM
human_password_login_duration........: min=652ms avg=7.16s max=1m9s p(50)=4.76s p(95)=16.62s p(99)=1m2s
login_ui_enter_login_name_duration...: min=65.11ms avg=3.4s max=1m0s p(50)=400.69ms p(95)=11.5s p(99)=59.35s
login_ui_enter_password_duration.....: min=597.54µs avg=25.21ms max=8.43s p(50)=2.77ms p(95)=6.61ms p(99)=459.33ms
login_ui_init_login_duration.........: min=29.53ms avg=505.93ms max=6.4s p(50)=94.64ms p(95)=1.77s p(99)=2.52s
login_ui_token_duration..............: min=41.07ms avg=651.58ms max=7.5s p(50)=161ms p(95)=2.2s p(99)=3.04s
oidc_user_info_duration..............: min=11.81ms avg=103.78ms max=2.79s p(50)=31.68ms p(95)=334.09ms p(99)=489.53ms
org_create_org_duration..............: min=47.19ms avg=47.19ms max=47.19ms p(50)=47.19ms p(95)=47.19ms p(99)=47.19ms
user_create_human_duration...........: min=349.88ms avg=3.46s max=6.17s p(50)=3.42s p(95)=5.8s p(99)=6.14s
HTTP
http_req_duration....................: min=597.54µs avg=1.58s max=1m0s p(50)=146.67ms p(95)=4.08s p(99)=1m0s
{ expected_response:true }.........: min=1.3ms avg=879.85ms max=1m0s p(50)=141.02ms p(95)=3.46s p(99)=9.21s
http_req_failed......................: 1.35% 9227 out of 683256
http_reqs............................: 683256 367.436785/s
EXECUTION
iteration_duration...................: min=652.1ms avg=11.96s max=1m9s p(50)=5.2s p(95)=1m0s p(99)=1m2s
iterations...........................: 90671 48.760436/s
vus..................................: 0 min=0 max=600
vus_max..............................: 600 min=600 max=600
NETWORK
data_received........................: 1.5 GB 810 kB/s
data_sent............................: 325 MB 175 kB/s
running (30m59.5s), 000/600 VUs, 90671 complete and 0 interrupted iterations
default ✓ [ 100% ] 600 VUs 30m0sWas this page helpful?