IAM and PAM systems must handle authentication traffic that is both high-volume and bursty (Monday morning logins, incident-driven privilege elevation). Performance engineering ensures that authentication latency remains acceptable under peak load and that the platform can scale to meet growing demand.
Performance Dimensions
Dimension
Metric
Target
Impact of Degradation
Authentication latency
Time to complete login (IdP)
< 1 second (with MFA: < 3 seconds)
User frustration, app timeouts
Token issuance
Tokens per second
Sustained peak × 1.5 buffer
App access failures, login failures
Directory lookup
LDAP search response time
< 50ms average, < 200ms p99
Auth latency, authorisation latency
PAM session initiation
Time to establish proxied session
< 5 seconds
Admin productivity loss
Session recording ingest
Write throughput to recording storage
> 2x peak concurrent recording bitrate
Lost recordings, compliance gaps
Provisioning throughput
User account operations per minute
Peak new-hire day × 2 buffer
Delayed access, productivity loss
API response time
REST API request duration
< 500ms average, < 2s p99
Slow UIs, automation timeouts
Authentication Performance
Factors Affecting Auth Performance
Factor
Impact
Mitigation
Directory lookup latency
High — each auth event may require 1-5 directory lookups
PAM session recording storage grows faster than most organisations expect. A medium-sized deployment (50 admins, RDP medium quality) generates ~1.8 TB per month. Plan for compression (typically 5:1 to 20:1 for RDP), retention policies aligned with compliance requirements, and tiered storage (fast SSD for recent recordings, S3/object storage for archival). Implement lifecycle policies to move recordings to cheaper storage tiers after 30-90 days.
- Auth rate per user = Average auth events per user per hour / 3600
- Growth factor = Projected user growth over planning horizon (typically 12-24 months)
- Buffer = 1.5 (50% headroom for unexpected spikes)
Example Capacity Calculation
Variable
Value
Source
Total users
50,000
HRIS headcount
Peak concurrency
30%
Historical Monday peak
Auth rate per user
2/hour
Average SSO app usage
Peak auths per second
50,000 × 0.3 × 2 / 3600 = 8.3
Calculation
Growth factor (24 months)
1.2 (20% growth)
Business plan
Buffer
1.5
Standard headroom
Required capacity
8.3 × 1.2 × 1.5 = ~15 auths/sec
Final target
Capacity Monitoring Thresholds
Metric
Warning (Alert)
Critical (Auto-scale)
Action
IdP CPU
> 60%
> 80%
Add IdP nodes
IdP memory
> 70%
> 85%
Add IdP nodes
Directory CPU
> 50%
> 75%
Add directory replicas
Redis memory
> 70%
> 85%
Add Redis replicas
Session recording storage
> 70% capacity
> 85% capacity
Add storage, review retention
Authentication latency (p99)
> 2s
> 5s
Scale out IdP, check directory
API response time (p99)
> 2s
> 5s
Scale out API tier
Key Takeaways
IAM/PAM performance has six critical dimensions: authentication latency (< 1s without MFA, < 3s with MFA), token issuance rate, directory lookup speed (< 50ms average), PAM session initiation (< 5s), session recording ingest, and provisioning throughput
Authentication performance is affected by directory latency, MFA latency, token signing, network round trips, session store access, and policy evaluation — horizontal scaling of stateless IdP nodes is the most effective scalability approach
Directory performance tuning requires proper indexing of search attributes, connection pooling (10-50 per app server), entry cache sizing (50%+ of directory data), thread pool tuning, and page size configuration (1000)
PAM session recording storage grows faster than expected — a 50-admin RDP deployment generates ~1.8 TB/month — plan for compression, retention policies, and tiered storage with lifecycle transitions
Caching strategy has four layers: local (in-process, short TTL for groups/roles/policies), distributed (Redis for sessions/tokens), read replicas (directory lookups), and CDN (static IdP metadata, JWKS) — each layer has specific TTL and invalidation requirements
Capacity planning follows the formula: Peak concurrent users × Auth rate per user × Growth factor × Buffer (1.5x) — monitor CPU (>60% warning, >80% auto-scale), memory, directory load, Redis memory, storage, and latency at p99 to trigger scaling actions
Load testing must cover peak, steady state, burst, MFA surge, provisioning peak, directory search, and PAM session rush scenarios — use tools like JMeter, k6, Locust, Gatling, or Vegeta depending on protocol and scripting requirements