machine pat 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 17:06:10 UTC |
| Test end | 2026-08-27 17:36:10 UTC |
| Test duration | 30min |
| Executed test | machine_pat_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 29%, p99 46% (peak 50%) Memory: p50 6%, peak 14% Instances: 7 (constant), no container startups recorded Server-side: 3,562 req/s, latency p50 11ms / p95 863ms / p99 1.0s |
| Observed errors | 29 of 6,335,633 requests failed (0.00%): 29x connection reset. 29 of 6,335,036 checks failed (0.00%): userinfo status ok (29 failed) |
| Top 3 most expensive database queries | 1: Load user with primary login name and human profile (2,135 s) 2: Query events by instance_id, aggregate_types, event_types, position (paged) (1,778 s) 3: Query events by aggregate_id, event_types and created_at (474 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: 86% median, 95% peak Memory: 40% Connections: 46 Transactions: 21,329/s IOPS: read 0, write 12 CPU-saturated — the bottleneck for this target. |
| k6 Iterations per second | 3452 |
| k6 output | output |
| flowchart outcome | Scale. Database CPU is the limit: 86% median against ZITADEL at 29%, with advisory lock wait only 0% of the top-5 query time. Raising the database beyond 8 vCPU is the next step, and throughput should be re-measured against the increase. |
Endpoint latencies
k6 output
█ TOTAL RESULTS
checks_total.......: 6335036 3453.251902/s
checks_succeeded...: 99.99% 6335007 out of 6335036
checks_failed......: 0.00% 29 out of 6335036
✓ user defined
✓ authorize status ok
✓ login name status ok
✓ login shows password page
✓ password status ok
✓ password callback
✓ code set
✓ token status ok
✓ access token created
✓ id token created
✓ info created
✓ org created
✓ create user is status ok
✓ add pat status ok
✓ openid configuration
✗ userinfo status ok
↳ 99% — ✓ 6333194 / ✗ 29
✓ org removed
CUSTOM
login_ui_enter_login_name_duration...: min=258.33ms avg=258.33ms max=258.33ms p(50)=258.33ms p(95)=258.33ms p(99)=258.33ms
login_ui_enter_password_duration.....: min=15.09ms avg=15.09ms max=15.09ms p(50)=15.09ms p(95)=15.09ms p(99)=15.09ms
login_ui_init_login_duration.........: min=77.89ms avg=77.89ms max=77.89ms p(50)=77.89ms p(95)=77.89ms p(99)=77.89ms
login_ui_token_duration..............: min=115.52ms avg=115.52ms max=115.52ms p(50)=115.52ms p(95)=115.52ms p(99)=115.52ms
oidc_user_info_duration..............: min=0s avg=170.27ms max=5.6s p(50)=24.52ms p(95)=872.17ms p(99)=1s
org_create_org_duration..............: min=85.33ms avg=85.33ms max=85.33ms p(50)=85.33ms p(95)=85.33ms p(99)=85.33ms
user_add_machine_pat_duration........: min=32.07ms avg=290.84ms max=519.66ms p(50)=321.25ms p(95)=460.73ms p(99)=480.62ms
user_create_machine_duration.........: min=62.02ms avg=529.19ms max=757.86ms p(50)=580.59ms p(95)=686.54ms p(99)=718.02ms
HTTP
http_req_duration....................: min=0s avg=170.29ms max=5.6s p(50)=24.53ms p(95)=872.12ms p(99)=1s
{ expected_response:true }.........: min=9.31ms avg=170.29ms max=5.6s p(50)=24.53ms p(95)=872.12ms p(99)=1s
http_req_failed......................: 0.00% 29 out of 6335633
http_reqs............................: 6335633 3453.577329/s
EXECUTION
iteration_duration...................: min=349.8µs avg=170.49ms max=5.6s p(50)=24.71ms p(95)=872.38ms p(99)=1s
iterations...........................: 6333223 3452.263629/s
vus..................................: 0 min=0 max=600
vus_max..............................: 600 min=600 max=600
NETWORK
data_received........................: 5.4 GB 2.9 MB/s
data_sent............................: 508 MB 277 kB/s
running (30m34.5s), 000/600 VUs, 6333223 complete and 0 interrupted iterations
default ✓ [ 100% ] 600 VUs 30m0sWas this page helpful?