add 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 14:58:50 UTC |
| Test end | 2026-08-27 15:28:51 UTC |
| Test duration | 30min |
| Executed test | add_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 18%, p99 26% (peak 28%) Memory: p50 6%, peak 12% Instances: 7 (constant), no container startups recorded Server-side: 790 req/s, latency p50 80ms / p95 3.5s / p99 3.9s |
| Observed errors | 1 of 1,416,546 requests failed (0.00%): none of the 1 individually logged (see k6 output). 1 of 2,831,284 checks failed (0.00%): add Session status ok (1 failed) |
| Top 3 most expensive database queries | 1: Push events (eventstore.push) (5,059 s)2: Query events by instance_id, aggregate_types, event_types, position (paged) (3,497 s) 3: Shared advisory lock on events2, taken by every push — lock wait (585 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: 97% median, 98% peak Memory: 40% Connections: 46 Transactions: 9,895/s IOPS: read 0, write 787 CPU-saturated — the bottleneck for this target. |
| k6 Iterations per second | 767 |
| k6 output | output |
| flowchart outcome | Scale. Database CPU is the limit: 97% median against ZITADEL at 18%, with advisory lock wait only 6% 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.......: 2831284 1533.737688/s
checks_succeeded...: 99.99% 2831283 out of 2831284
checks_failed......: 0.00% 1 out of 2831284
✓ 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 Session status ok
↳ 99% — ✓ 1415335 / ✗ 1
✓ add session is status ok
✓ org removed
CUSTOM
add_session_duration.................: min=23ms avg=763.11ms max=7.69s p(50)=96ms p(95)=3.53s p(99)=4.15s
login_ui_enter_login_name_duration...: min=210.14ms avg=210.14ms max=210.14ms p(50)=210.14ms p(95)=210.14ms p(99)=210.14ms
login_ui_enter_password_duration.....: min=18.75ms avg=18.75ms max=18.75ms p(50)=18.75ms p(95)=18.75ms p(99)=18.75ms
login_ui_init_login_duration.........: min=230.06ms avg=230.06ms max=230.06ms p(50)=230.06ms p(95)=230.06ms p(99)=230.06ms
login_ui_token_duration..............: min=137.93ms avg=137.93ms max=137.93ms p(50)=137.93ms p(95)=137.93ms p(99)=137.93ms
org_create_org_duration..............: min=57.15ms avg=57.15ms max=57.15ms p(50)=57.15ms p(95)=57.15ms p(99)=57.15ms
session_add_session_duration.........: min=21.8ms avg=761.9ms max=7.69s p(50)=95.24ms p(95)=3.53s p(99)=4.15s
user_create_human_duration...........: min=464.18ms avg=3.23s max=5.82s p(50)=3.06s p(95)=5.61s p(99)=5.75s
HTTP
http_req_duration....................: min=18.75ms avg=762.65ms max=12.57s p(50)=95.25ms p(95)=3.53s p(99)=4.15s
{ expected_response:true }.........: min=18.75ms avg=762.65ms max=12.57s p(50)=95.25ms p(95)=3.53s p(99)=4.15s
http_req_failed......................: 0.00% 1 out of 1416546
http_reqs............................: 1416546 767.358551/s
EXECUTION
iteration_duration...................: min=23.47ms avg=763.22ms max=7.69s p(50)=96.45ms p(95)=3.53s p(99)=4.15s
iterations...........................: 1415336 766.703081/s
vus..................................: 0 min=0 max=600
vus_max..............................: 600 min=600 max=600
NETWORK
data_received........................: 1.1 GB 584 kB/s
data_sent............................: 235 MB 127 kB/s
running (30m46.0s), 000/600 VUs, 1415336 complete and 0 interrupted iterations
default ✓ [ 100% ] 600 VUs 30m0sWas this page helpful?