introspect 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 15:31:22 UTC |
| Test end | 2026-08-27 16:01:22 UTC |
| Test duration | 30min |
| Executed test | introspect |
| 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 39%, p99 50% (peak 58%) Memory: p50 6%, peak 15% Instances: 7 (constant), no container startups recorded Server-side: 2,325 req/s, latency p50 33ms / p95 1.1s / p99 1.3s |
| Observed errors | 1,400 of 4,159,863 requests failed (0.03%): 2x connection reset, 1,398x not individually logged (see k6 output). 2,800 of 8,317,316 checks failed (0.03%): introspect status ok (1400 failed), introspect active (1400 failed) |
| Top 3 most expensive database queries | 1: Query events by aggregate_id and event_types, ordered by sequence (4,034 s) 2: Query events by instance_id, aggregate_types, event_types, position (paged) (1,765 s) 3: Load user with primary login name and human profile (1,497 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: 98% median, 99% peak Memory: 40% Connections: 46 Transactions: 11,597/s IOPS: read 0, write 10 CPU-saturated — the bottleneck for this target. |
| k6 Iterations per second | 2297 |
| k6 output | output |
| flowchart outcome | Scale. Database CPU is the limit: 98% median against ZITADEL at 39%, 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.......: 8317316 4594.588805/s
checks_succeeded...: 99.96% 8314516 out of 8317316
checks_failed......: 0.03% 2800 out of 8317316
✓ 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
✓ add project status ok
✓ add api status ok
✓ add app key status ok
✓ openid configuration
✗ introspect status ok
↳ 99% — ✓ 4156046 / ✗ 1400
✗ introspect active
↳ 99% — ✓ 4156046 / ✗ 1400
✓ org removed
CUSTOM
app_add_app_duration.................: min=38.25ms avg=444.17ms max=964.29ms p(50)=442.27ms p(95)=874.88ms p(99)=906.87ms
app_add_app_key_duration.............: min=110.68ms avg=1.1s max=2.09s p(50)=1.13s p(95)=1.87s p(99)=1.93s
login_ui_enter_login_name_duration...: min=153.7ms avg=159.94ms max=166.17ms p(50)=159.94ms p(95)=165.55ms p(99)=166.05ms
login_ui_enter_password_duration.....: min=5.47ms avg=8.75ms max=12.03ms p(50)=8.75ms p(95)=11.7ms p(99)=11.96ms
login_ui_init_login_duration.........: min=64.27ms avg=78.53ms max=92.79ms p(50)=78.53ms p(95)=91.37ms p(99)=92.51ms
login_ui_token_duration..............: min=157.39ms avg=205.82ms max=254.26ms p(50)=205.82ms p(95)=249.41ms p(99)=253.29ms
oidc_introspect_duration.............: min=12.32ms avg=259.25ms max=23.99s p(50)=46.46ms p(95)=1.16s p(99)=1.36s
org_create_org_duration..............: min=56.57ms avg=56.57ms max=56.57ms p(50)=56.57ms p(95)=56.57ms p(99)=56.57ms
project_add_project_duration.........: min=41.65ms avg=355.6ms max=749.58ms p(50)=352.72ms p(95)=626.33ms p(99)=682.79ms
HTTP
http_req_duration....................: min=5.47ms avg=259.38ms max=23.99s p(50)=46.49ms p(95)=1.16s p(99)=1.36s
{ expected_response:true }.........: min=5.47ms avg=258.8ms max=23.99s p(50)=46.47ms p(95)=1.16s p(99)=1.36s
http_req_failed......................: 0.03% 1400 out of 4159863
http_reqs............................: 4159863 2297.960059/s
EXECUTION
iteration_duration...................: min=12.55ms avg=259.71ms max=23.99s p(50)=46.87ms p(95)=1.16s p(99)=1.36s
iterations...........................: 4157446 2296.624878/s
vus..................................: 0 min=0 max=600
vus_max..............................: 600 min=600 max=600
NETWORK
data_received........................: 195 GB 108 MB/s
data_sent............................: 5.1 GB 2.8 MB/s
running (30m10.2s), 000/600 VUs, 4157446 complete and 0 interrupted iterations
default ✓ [ 100% ] 600 VUs 30m0sWas this page helpful?