user info 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 18:11:39 UTC |
| Test end | 2026-08-27 18:41:40 UTC |
| Test duration | 30min |
| Executed test | user_info |
| 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 26%, p99 42% (peak 44%) Memory: p50 6%, peak 14% Instances: 7 (constant), no container startups recorded Server-side: 3,303 req/s, latency p50 16ms / p95 939ms / p99 1.1s |
| Observed errors | 66 of 5,800,788 requests failed (0.00%): 1x connection reset, 65x not individually logged (see k6 output). 66 of 5,800,793 checks failed (0.00%): userinfo status ok (65 failed), org removed (1 failed) |
| Top 3 most expensive database queries | 1: Push events (eventstore.push) (3,583 s)2: Query events by instance_id, aggregate_types, event_types, position (paged) (3,576 s) 3: Load user with primary login name and human profile (2,149 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: 16,545/s IOPS: read 0, write 12 CPU-saturated — the bottleneck for this target. |
| k6 Iterations per second | 3217 |
| k6 output | output |
| flowchart outcome | Scale. Database CPU is the limit: 96% median against ZITADEL at 26%, with advisory lock wait only 15% 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.......: 5800793 3217.417923/s
checks_succeeded...: 99.99% 5800727 out of 5800793
checks_failed......: 0.00% 66 out of 5800793
✓ 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
✓ openid configuration
✗ userinfo status ok
↳ 99% — ✓ 5800103 / ✗ 65
✗ org removed
↳ 0% — ✓ 0 / ✗ 1
CUSTOM
login_ui_enter_login_name_duration...: min=118.36ms avg=118.43ms max=118.51ms p(50)=118.43ms p(95)=118.5ms p(99)=118.51ms
login_ui_enter_password_duration.....: min=21.98ms avg=243.15ms max=464.31ms p(50)=243.15ms p(95)=442.2ms p(99)=459.89ms
login_ui_init_login_duration.........: min=78.54ms avg=81.56ms max=84.59ms p(50)=81.56ms p(95)=84.29ms p(99)=84.53ms
login_ui_token_duration..............: min=75.08ms avg=88.39ms max=101.7ms p(50)=88.39ms p(95)=100.37ms p(99)=101.44ms
oidc_user_info_duration..............: min=1.77ms avg=185.96ms max=3.47s p(50)=29.32ms p(95)=942.89ms p(99)=1.13s
org_create_org_duration..............: min=52.63ms avg=52.63ms max=52.63ms p(50)=52.63ms p(95)=52.63ms p(99)=52.63ms
user_create_human_duration...........: min=364.77ms avg=364.77ms max=364.77ms p(50)=364.77ms p(95)=364.77ms p(99)=364.77ms
HTTP
http_req_duration....................: min=1.77ms avg=185.95ms max=3.47s p(50)=29.32ms p(95)=942.88ms p(99)=1.13s
{ expected_response:true }.........: min=4.1ms avg=185.93ms max=3.47s p(50)=29.32ms p(95)=942.85ms p(99)=1.13s
http_req_failed......................: 0.00% 66 out of 5800788
http_reqs............................: 5800788 3217.41515/s
EXECUTION
iteration_duration...................: min=2ms avg=186.18ms max=3.47s p(50)=29.51ms p(95)=943.09ms p(99)=1.13s
iterations...........................: 5800168 3217.071266/s
vus..................................: 600 min=0 max=600
vus_max..............................: 600 min=600 max=600
NETWORK
data_received........................: 4.0 GB 2.2 MB/s
data_sent............................: 458 MB 254 kB/s
running (30m02.9s), 000/600 VUs, 5800168 complete and 0 interrupted iterations
default ✓ [ 100% ] 600 VUs 30m0sWas this page helpful?