Chapter 36 — Identity and access management: performance and scale
Lesson map
Lesson 36 published. Map, example, EX106.
flowchart TD
N0["Learning outcomes"]
N1["36.1 Load components"]
N2["Lab — Peak load estimate"]
N3["36.2 Reading the estimate"]
N4["36.3 Load testing safely"]
N5["36.4 Growth planning"]
N6["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Worked example"]
EX --> Q["Exercise EX106"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["36.1 Load components"]
N2["Lab — Peak load estimate"]
N3["36.2 Reading the estimate"]
N4["36.3 Load testing safely"]
N5["36.4 Growth planning"]
N6["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX106"]
[Learning outcomes]
|
v
[36.1 Load components]
|
v
[Lab — Peak load estimate]
|
v
[36.2 Reading the estimate]
|
v
[36.3 Load testing safely]
|
v
[36.4 Growth planning]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX106]
Learning outcomes
You will (1) estimate provider load from sign-in and refresh rates; (2) plan for growth; (3) test performance safely.
36.1 Load components
Provider load has two main parts: interactive sign-ins and application token requests at the morning peak, and background token refreshes through the day as applications renew access. Sana estimates each from staff numbers, applications per person and arrival patterns measured during the pilot. Separating the components matters, because they respond differently to change: adding applications increases both, while lengthening token lifetimes reduces refreshes but increases the time a stolen token remains useful, which is a security trade-off. Both components are measured separately during the pilot.
Lab — Peak load estimate
"""Estimate identity provider load at the morning peak from synthetic rates (stdlib only)."""
staff, apps, arrive_share, window_s = 2400, 6, 0.60, 600
signin = staff * arrive_share * apps / window_s
refresh = staff * apps * 0.8 / 3600
cap_per_server = 60
for label, f in [("now", 1.0), ("+40% growth", 1.4)]:
s, r = signin * f, refresh * f; t = s + r
print(f"{label:12} app sign-ins/s={s:.1f} refresh/s={r:.1f} total/s={t:.1f} one-server utilisation={t/cap_per_server:.0%}")
Run with python3 lab_load.py. Verified output:
now app sign-ins/s=14.4 refresh/s=3.2 total/s=17.6 one-server utilisation=29%
+40% growth app sign-ins/s=20.2 refresh/s=4.5 total/s=24.6 one-server utilisation=41%
36.2 Reading the estimate
With 2,400 staff, six applications each and sixty percent arriving within ten minutes, the synthetic model gives about 14.4 application sign-ins per second plus 3.2 refreshes, around 17.6 requests per second, or 29 percent of one server's tested capacity. With forty percent growth in staff or applications, load rises to about 24.6 per second, 41 percent. These figures match the earlier calculus estimate and leave room for one server to fail. Sana treats them as estimates to be confirmed by load testing, not as guarantees.
Even after growth, 24.6 requests per second would use 41 percent of one server, so a single surviving server could still carry the load.
36.3 Load testing safely
Load tests run only in the test tenant, with synthetic users and the provider's documented testing rules, because generating large volumes of sign-ins against a production cloud service may breach its terms and could affect real staff. Sana ramps load gradually, watching latency percentiles and error rates, and stops at defined limits. The test confirms capacity and reveals a slow group-membership lookup for users with many groups, which is fixed by trimming nested groups in the directory. Results are stored as evidence with the configuration version.
36.4 Growth planning
Sana writes a growth plan: review load estimates every six months, recalculate when a large application is integrated and watch the morning-peak 95th percentile latency as an early warning. For cloud providers, capacity is often handled by the vendor, but limits on requests per tenant still apply and must be known. The plan also covers the council's side, such as internet link capacity and the HR feed's processing time, which grow with staff numbers even when the provider itself scales automatically.
Worked example
The model estimates about 17.6 requests per second now and 24.6 after 40 percent growth; test-tenant load testing confirms capacity and finds a slow lookup for users in many nested groups.
Synthetic case. Rates, capacity and findings are synthetic.
Errors and limits
Load testing against production cloud identity services can breach terms and affect real staff.
Exercises
- EX106 — Peak estimate. What total peak load does the lab estimate now? Rubric: 3 = about 17.6 requests per second, 29%;; 2 = 17.6;; 1 = 4.4;; 0 = none.
- EX107 — Lifetime trade-off. What is the trade-off in lengthening token lifetimes? Rubric: 3 = fewer refreshes but stolen tokens useful longer;; 2 = security vs load;; 1 = vague;; 0 = none.
- EX108 — Load test finding. What did load testing reveal? Rubric: 3 = slow lookup for users with many nested groups;; 2 = nested groups;; 1 = vague;; 0 = none.
Synthesis
Separating load components, confirming estimates in a test tenant and planning growth keep sign-in fast as the council grows.
Continue studying — chapter 36 of 50
← Chapter 35 (draft) · Course chapter index · Chapter 37 (draft) →