oidc session 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:38:43 UTC |
| Test end | 2026-08-27 18:08:45 UTC |
| Test duration | 30min |
| Executed test | oidc_session |
| 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 20%, p99 34% (peak 37%) Memory: p50 6%, peak 12% Instances: 7 (constant), no container startups recorded Server-side: 1,001 req/s, latency p50 59ms / p95 2.8s / p99 3.3s |
| Observed errors | 3 of 1,767,162 requests failed (0.00%): 2x connection reset, 1x not individually logged (see k6 output). 3 of 2,355,414 checks failed (0.00%): add Session status ok (1 failed), finalize auth request status ok (2 failed) |
| Top 3 most expensive database queries | 1: Push events (eventstore.push) (3,945 s)2: Query events by instance_id, aggregate_types, event_types, position (paged) (3,572 s) 3: Shared advisory lock on events2, taken by every push — lock wait (1,973 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: 92% median, 94% peak Memory: 40% Connections: 46 Transactions: 10,721/s IOPS: read 1, write 1,086 CPU-saturated — the bottleneck for this target. |
| k6 Iterations per second | 326 |
| k6 output | output |
| flowchart outcome | Scale. Database CPU is the limit: 92% median against ZITADEL at 20%, with advisory lock wait only 20% 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.......: 2355414 1305.538291/s
checks_succeeded...: 99.99% 2355411 out of 2355414
checks_failed......: 0.00% 3 out of 2355414
✓ 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
✓ generate machine key status ok
✓ member added successful
✓ openid configuration
✓ access token returned
✓ auth request id returned
✗ add Session status ok
↳ 99% — ✓ 588848 / ✗ 1
✗ finalize auth request status ok
↳ 99% — ✓ 588846 / ✗ 2
✓ org removed
CUSTOM
login_ui_enter_login_name_duration...: min=114.02ms avg=114.02ms max=114.02ms p(50)=114.02ms p(95)=114.02ms p(99)=114.02ms
login_ui_enter_password_duration.....: min=23.78ms avg=23.78ms max=23.78ms p(50)=23.78ms p(95)=23.78ms p(99)=23.78ms
login_ui_init_login_duration.........: min=14.73ms avg=272.65ms max=4.22s p(50)=49.2ms p(95)=1.11s p(99)=1.37s
login_ui_token_duration..............: min=128.22ms avg=128.22ms max=128.22ms p(50)=128.22ms p(95)=128.22ms p(99)=128.22ms
membership_iam_member................: min=70.51ms avg=70.51ms max=70.51ms p(50)=70.51ms p(95)=70.51ms p(99)=70.51ms
oidc_auth_request_finalize...........: min=27.3ms avg=833.77ms max=9s p(50)=97.44ms p(95)=3.96s p(99)=4.92s
oidc_session_duration................: min=83ms avg=1.83s max=24.62s p(50)=1.21s p(95)=5.21s p(99)=7.4s
oidc_token_duration..................: min=47.51ms avg=47.51ms max=47.51ms p(50)=47.51ms p(95)=47.51ms p(99)=47.51ms
org_create_org_duration..............: min=82.6ms avg=82.6ms max=82.6ms p(50)=82.6ms p(95)=82.6ms p(99)=82.6ms
session_add_session_duration.........: min=22.85ms avg=723.73ms max=23.09s p(50)=79.29ms p(95)=3.51s p(99)=4.36s
user_add_machine_key_duration........: min=55.76ms avg=55.76ms max=55.76ms p(50)=55.76ms p(95)=55.76ms p(99)=55.76ms
user_create_machine_duration.........: min=75.7ms avg=75.7ms max=75.7ms p(50)=75.7ms p(95)=75.7ms p(99)=75.7ms
HTTP
http_req_duration....................: min=0s avg=609.87ms max=23.09s p(50)=77.47ms p(95)=3.41s p(99)=4.43s
{ expected_response:true }.........: min=11.94ms avg=609.87ms max=23.09s p(50)=77.47ms p(95)=3.41s p(99)=4.43s
http_req_failed......................: 0.00% 3 out of 1767162
http_reqs............................: 1767162 979.487113/s
EXECUTION
iteration_duration...................: min=83.46ms avg=1.83s max=24.62s p(50)=1.21s p(95)=5.21s p(99)=7.4s
iterations...........................: 588849 326.382079/s
vus..................................: 13 min=0 max=600
vus_max..............................: 600 min=600 max=600
NETWORK
data_received........................: 1.3 GB 704 kB/s
data_sent............................: 576 MB 319 kB/s
running (30m04.2s), 000/600 VUs, 588849 complete and 0 interrupted iterations
default ✓ [ 100% ] 600 VUs 30m0sWas this page helpful?