Load Testing Reports

Authrim’s OAuth 2.0/OIDC endpoints have been rigorously tested using K6 Cloud distributed load testing to verify performance, stability, and zero-error operation under production-like conditions.

Executive Summary

3,500 RPS

Peak Token Operations (Silent Auth)

Zero errors up to 3,500 requests/second for session-based authentication

150 LPS

Full Login Flow

Complete OAuth flow including OTP verification at 150 logins/second

100%

Token Validation Accuracy

Perfect accuracy across all token types (valid, expired, revoked)

Error Rate

Zero HTTP errors within recommended capacity limits

Test Environment

Component	Configuration
Load Generator	K6 Cloud (Amazon US Portland / Tokyo)
Target	Cloudflare Workers (conformance.authrim.com)
Infrastructure	Workers + Durable Objects + D1 + KV
Test Period	December 2025
Test Duration	3-5 minutes per scenario

Endpoint Capacity Overview

Endpoint	Recommended RPS	Peak RPS	Latency P95	Details
Silent Auth	2,500	3,500	<500ms	View Report →
UserInfo	2,000	2,500	<350ms	View Report →
Token Exchange	1,500	2,500	<300ms	View Report →
Refresh Token	2,500	3,000	<500ms	View Report →
Token Introspection	300	500	<350ms	View Report →
Full Login (OTP)	100	150	<800ms	View Report →

RPS vs Latency

Silent Authentication with session cookies (prompt=none):

RPS	P50	P95	P99	Status
500	407ms	454ms	536ms	✅
1,000	403ms	453ms	528ms	✅
1,500	404ms	471ms	530ms	✅
2,000	405ms	452ms	528ms	✅
2,500	652ms	794ms	838ms	✅
3,000	1,243ms	1,583ms	1,642ms	✅
3,500	615ms	1,631ms	1,727ms	✅
4,000	458ms	669ms	5,622ms	⚠️

Configuration: 64 shards, 500 pre-created sessions

Bearer token validation with JWT RS256:

RPS	P50	P95	P99	Status
1,000	114ms	139ms	200ms	✅
2,000	118ms	254ms	350ms	✅
2,500	127ms	325ms	585ms	⚠️
3,000	150ms	1,032ms	1,736ms	⚠️

Features: JWK caching, User data caching (KV)

RFC 8693 Token Exchange for microservice auth:

RPS	P50	P95	P99	Status
2,000	112ms	500ms	589ms	⚠️
2,500	76ms	225ms	297ms	✅
3,000	1,657ms	2,144ms	2,269ms	❌

Features: Mixed token types (70% valid, 10% expired, 10% invalid, 10% revoked)

Token rotation with theft detection:

RPS	P50	P95	P99	Status
200	9ms (Worker)	-	816ms	✅
3,000 (32 shards)	12ms	100ms	781ms	⚠️
3,000 (48 shards)	12ms	39ms	43ms	✅

Key Finding: Increasing shards from 32→48 reduced DO P99 from 781ms to 43ms

Key Findings

1. Sharding is Critical for Scale

Durable Object sharding directly impacts performance at high RPS:

Test	Shards	Result
Refresh Token @3000 RPS	32 → 48	DO Errors: 11,972 → 0
Silent Auth @4000 RPS	64 → 128	HTTP Failures: 160 → 0
Full Login @100 LPS	16 → 32	DO Errors: 443 → 0

2. Worker CPU is Not the Bottleneck

Across all tests, Worker CPU time remained stable:

P50: 2-3ms (all endpoints)
P99: 5-15ms (even at peak load)

The bottleneck is Durable Object wall time (queue waiting), not CPU processing.

3. Caching Effectiveness

Cache Type	Impact
JWK Cache (DO)	JWT verification stays at 2ms P50
User Cache (KV)	D1 reads reduced by 96%
RBAC Cache	Claims fetched once per 5 minutes

At 150 LPS, each step contributes:

Step	Avg	P95
AuthorizeInit	106ms	129ms
EmailCodeGenerate	217ms	279ms
EmailCodeVerify	260ms	336ms
AuthorizeCode	68ms	88ms
Total	652ms	756ms

Capacity Recommendations

Conservative (Production)

For SLA-guaranteed operation with P99 < 1 second:

Endpoint	Max RPS	Monthly Volume
Silent Auth	2,000	5.2 billion
Token Operations	2,500	6.5 billion
Full Login	100	260 million

Peak (Burst Traffic)

For short bursts with acceptable latency degradation:

Endpoint	Max RPS	Notes
Silent Auth	3,500	P99 ~1.7s
Token Operations	3,000	Zero errors
Full Login	150	P95 < 800ms

Architecture Impact

flowchart TB
    subgraph K6["K6 Cloud (Distributed)"]
        LZ1["Portland Load Zone"]
        LZ2["Tokyo Load Zone"]
    end

    subgraph CF["Cloudflare Edge"]
        W["Workers"]
        DO["Durable Objects (Sharded)"]
        KV["KV Cache"]
        D1["D1 Database"]
    end

    K6 -->|HTTPS| W
    W --> DO
    W --> KV
    W --> D1
    DO --> D1