machine jwt profile grant 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 16:34:57 UTC |
| Test end | 2026-08-27 17:04:57 UTC |
| Test duration | 30min |
| Executed test | machine_jwt_profile_grant |
| 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 22%, p99 31% (peak 36%) Memory: p50 6%, peak 13% Instances: 7 (constant), no container startups recorded Server-side: 1,108 req/s, latency p50 70ms / p95 2.6s / p99 2.8s |
| Observed errors | 97 of 1,986,156 requests failed (0.00%): none of the 97 individually logged (see k6 output). 194 of 3,969,305 checks failed (0.00%): token status ok (97 failed), access token returned (97 failed) |
| Top 3 most expensive database queries | 1: Push events (eventstore.push) (6,040 s)2: Query events by instance_id, aggregate_types, event_types, position (paged) (1,773 s) 3: Load user with primary login name and human profile (1,022 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: 96% median, 97% peak Memory: 40% Connections: 46 Transactions: 8,909/s IOPS: read 0, write 887 CPU-saturated — the bottleneck for this target. |
| k6 Iterations per second | 1076 |
| k6 output | output |
| flowchart outcome | Scale. Database CPU is the limit: 96% median against ZITADEL at 22%, with advisory lock wait only 7% 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. Lock share fell from 64.8% to 7.3% when improvedPerformance was enabled, moving this target from lock-bound to CPU-bound. |
Endpoint latencies
k6 output
█ TOTAL RESULTS
checks_total.......: 3969305 2152.313897/s
checks_succeeded...: 99.99% 3969111 out of 3969305
checks_failed......: 0.00% 194 out of 3969305
✓ user defined
✓ authorize status ok
✓ login name status ok
✓ login shows password page
✓ password status ok
✓ password callback
✓ code set
✗ token status ok
↳ 99% — ✓ 1983650 / ✗ 97
✓ access token created
✓ id token created
✓ info created
✓ org created
✓ create user is status ok
✓ generate machine key status ok
✓ openid configuration
✗ access token returned
↳ 99% — ✓ 1983649 / ✗ 97
✓ org removed
CUSTOM
login_ui_enter_login_name_duration...: min=136.8ms avg=136.8ms max=136.8ms p(50)=136.8ms p(95)=136.8ms p(99)=136.8ms
login_ui_enter_password_duration.....: min=20.15ms avg=20.15ms max=20.15ms p(50)=20.15ms p(95)=20.15ms p(99)=20.15ms
login_ui_init_login_duration.........: min=96.66ms avg=96.66ms max=96.66ms p(50)=96.66ms p(95)=96.66ms p(99)=96.66ms
login_ui_token_duration..............: min=166.72ms avg=166.72ms max=166.72ms p(50)=166.72ms p(95)=166.72ms p(99)=166.72ms
oidc_token_duration..................: min=19.56ms avg=541.42ms max=5.37s p(50)=85.31ms p(95)=2.57s p(99)=2.93s
org_create_org_duration..............: min=63.41ms avg=63.41ms max=63.41ms p(50)=63.41ms p(95)=63.41ms p(99)=63.41ms
user_add_machine_key_duration........: min=28.22ms avg=167.45ms max=375.9ms p(50)=174.58ms p(95)=304.34ms p(99)=355.68ms
user_create_machine_duration.........: min=112.78ms avg=534.68ms max=798.43ms p(50)=541.02ms p(95)=722.05ms p(99)=769.68ms
HTTP
http_req_duration....................: min=12.65ms avg=541.03ms max=12.01s p(50)=85.34ms p(95)=2.57s p(99)=2.93s
{ expected_response:true }.........: min=12.65ms avg=541.04ms max=12.01s p(50)=85.33ms p(95)=2.57s p(99)=2.93s
http_req_failed......................: 0.00% 97 out of 1986156
http_reqs............................: 1986156 1076.972206/s
EXECUTION
iteration_duration...................: min=21.94ms avg=544.43ms max=5.38s p(50)=88.19ms p(95)=2.57s p(99)=2.93s
iterations...........................: 1983746 1075.665408/s
vus..................................: 0 min=0 max=600
vus_max..............................: 600 min=600 max=600
NETWORK
data_received........................: 3.2 GB 1.7 MB/s
data_sent............................: 1.7 GB 911 kB/s
running (30m44.2s), 000/600 VUs, 1983746 complete and 0 interrupted iterations
default ✓ [ 100% ] 600 VUs 30m0sWas this page helpful?