🖼️ See the drawing + lab 🏠 Course home 🌿 Branch on GitHub ✏️ View source

🖼️ आकृती आणि labThe drawing + lab पूर्ण पानावर उघडा ↗Open full page ↗

🏆 धडा 12 — Load tests, budgets आणि संपूर्ण चित्र: पात्रता वेळा

📍 तुम्ही इथे आहात: 12 पैकी धडा 12 · मागे: lesson-11-web-performance · शेवटचा धडा 🎓

📦 या ब्रँचमध्ये काय आहे

धडे 01–11, आणि ते वेगवान ठेवणे: load test traffic खाली latency कुठे वळते (knee) ते शोधतो, आणि CI मधील performance budget एखाद्या बदलाने गोष्टी बिघडल्या तर build fail करतो — प्रति page queries, bytes, LCP, p95. धडा कोर्सच्या संपूर्ण नकाशाने संपतो. perf/demo.py मधील budgets() आणि perf/sim.py मधील load_test आणि check_budget.

🧒 5 वर्षांच्या मुलाला समजावल्यासारखे

खऱ्या क्रीडा दिनाआधी शाळा एक रंगीत तालीम घेते. 🏟️ ते पाण्याच्या टेबलावरून अधिकाधिक धावपटू पाठवतात, ते केव्हा हळू होते हे पाहण्यासाठी.

सेकंदाला 50 धावपटू: ठीक, बहुतेक जणी काही क्षणच थांबतात.
सेकंदाला 70: बहुतेकींसाठी अजूनही ठीक, पण हळू असलेल्या जास्त वेळ थांबतात.
सेकंदाला 90: रांग लांब होते.
सेकंदाला 110: टेबल हाताळू शकते त्यापेक्षा जास्त. रांग फक्त वाढतच जाते. 😵

म्हणून आता त्यांना माहीत आहे: 90 च्या बऱ्याच खाली राहा.

मग दीपिका भिंतीवर पात्रता वेळा लिहिते 📝: "निकालाचे page office च्या जास्तीत जास्त 5 फेऱ्या वापरू शकते. ते 2.5 सेकंदांपेक्षा कमी वेळात दिसायला हवे. त्याचे वजन जास्तीत जास्त 500 KB असू शकते." कोणीही निकालाचा program बदलला की प्रत्येक वेळी एक मदतनीस पात्रता वेळा तपासते. बदलाने त्यातली एखादी मोडली, तर मदतनीस क्रीडा दिनाच्या दरम्यान नव्हे, तर आधीच "नाही — पुन्हा प्रयत्न करा" असे सांगते. ❌➡️✅

🗺️ आकृती

flowchart LR
    lt["🏟️ load test, open model<br/>10 ms a request"] --> r50["50/s → p95 60 ms"]
    r50 --> r70["70/s → p95 109 ms"]
    r70 --> r90["90/s → p95 280 ms"]
    r90 --> r110["110/s → p95 3122 ms<br/>above capacity"]
    b["📝 budget: queries ≤ 5 · LCP ≤ 2500 ms<br/>weight ≤ 500 KB · p95 ≤ 100 ms"] --> before["before: 51 · 5020 · 2210 · 109 → FAIL"]
    b --> after["after: 1 · 1055 · 452.5 · 23 → PASS"]

🗺️ रेखाटलेली आवृत्ती + एक lab: https://school-edh.pages.dev/performance/lesson-diagrams.html#l12

❓ काय

Load test — नियंत्रित प्रमाणात traffic पाठवा आणि latency percentiles, errors आणि throughput मोजा. प्रकार: load (अपेक्षित traffic), stress (त्याच्या पलीकडे, मोडण्याचा बिंदू शोधण्यासाठी), spike (अचानक उडी), soak (तासन् तास, leaks आणि हळू वाढ शोधण्यासाठी).
Knee — असा load जिथे latency हळू वाढणे थांबवून वेगाने वाढू लागते. धडा 09 च्या भाषेत, जिथे utilisation जास्त होते. त्याच्या खाली चालवण्याचा आराखडा करा.
Open विरुद्ध closed model — open load generator उत्तरे काहीही असोत, वेळापत्रकानुसार requests पाठवतो (खरे users येतात तसे). Closed generator पुढचा request पाठवण्याआधी प्रत्येक उत्तराची वाट पाहतो, त्यामुळे server हळू झाला की generator सुद्धा हळू होतो आणि test दावा करतो त्यापेक्षा कमी load पाठवतो. यातून होणाऱ्या मोजमापाच्या चुकीला Gil Tene ने coordinated omission असे नाव दिले. Lab चा load test open आहे.
Performance budget — अशी मर्यादा जी बदलाने मोडता कामा नये: प्रति page queries, page weight, bundle size, lab test मधला LCP, load test मधला p95. Budget "वर्षभरात ते हळू झाले" याचे रूपांतर "या commit ने ते हळू केले" मध्ये करतो.
CI मध्ये counts विरुद्ध वेळा — shared CI machines गोंगाटाच्या (noisy) असतात (धडा 02), त्यामुळे तिथे वेळेवर आधारित checks flaky होतात किंवा त्यांना मोठी सवलत लागते. Counts — queries, bytes, calls, allocations — प्रत्येक run मध्ये सारखेच असतात, म्हणून ते कडक, विश्वासार्ह gates बनतात. वेळा शांत, ठराविक machine वर, साठवलेल्या baseline शी तुलना करून तपासाव्यात.

🤔 का

कारण performance शांतपणे खालावते. कोणीही मुद्दाम N+1 जोडत नाही; तो प्रत्येक functional test पार केलेल्या छोट्या बदलातून येतो. CI मधील budget तो लिहिला गेला त्याच दिवशी पकडतो, जेव्हा उपाय एका ओळीचा असतो. आणि मोठ्या दिवसाआधीचा load test knee कुठे आहे ते सांगतो, जेव्हा तो हलवायला तुमच्याकडे अजून वेळ असतो.

🔧 कसे (या repo मध्ये)

perf/sim.py मधील load_test(rates, service_ms, n, seed) प्रत्येक rate वर धडा 09 चे simulate_queue (एक server, random arrivals, open model) चालवते आणि p50, p95 आणि p99 परत देते. check_budget(measured, budget) प्रत्येक मोजमापाची त्याच्या मर्यादेशी तुलना करते आणि rows आणि एकूण pass/fail परत देते. perf/demo.py मधील budgets() "before" values आधीच्या धड्यांमधून live मोजते — धडा 07 च्या N+1 मधील query count, धडा 11 मधले LCP आणि bytes — आणि "after" values त्यांच्या उपायांमधून. "After" p95 असे गृहीत धरतो की profile करून केलेल्या उपायाने service time 10 ms वरून 5 ms वर आणला: हे model चे एक input आहे.

🧪 करून पाहा

python3 perf/demo.py budgets
python3 - <<'EOF'
import sys; sys.path.insert(0, "perf"); from sim import load_test, check_budget
for r, p50, p95, p99 in load_test((60, 80, 95), service_ms=5.0):
    print(f"service 5 ms, {r} req/s → p95 {p95} ms")
rows, ok = check_budget({"SQL queries per page": 7, "page weight KB": 480}, {"SQL queries per page": 5, "page weight KB": 500})
for name, value, limit, good in rows: print(f"{name}: {value} / {limit} {'ok' if good else 'OVER'}")
print("PASS" if ok else "FAIL")
sys.exit(0 if ok else 1)
EOF
echo "exit code: $?"
python3 perf/demo.py
python3 perf/test_perf.py

✅ तपासा — तुम्हाला काय दिसायला हवे

budgets हे छापते:

── a load test (simulated, open model): one server, 10 ms per request, capacity about 100 requests/s
    50 req/s → p50    14 ms · p95    60 ms · p99    98 ms
    70 req/s → p50    25 ms · p95   109 ms · p99   160 ms
    90 req/s → p50    64 ms · p95   280 ms · p99   411 ms
   110 req/s → p50  1716 ms · p95  3122 ms · p99  3187 ms
   the knee: past about 80% busy, p95 climbs fast · above capacity the queue only grows
── budget check, before the fixes: SQL queries per page 51 / 5 ❌ · LCP ms (simulated) 5020 / 2500 ❌ · page weight KB 2210 / 500 ❌ · p95 ms at 70 req/s 109 / 100 ❌ → FAIL (the CI job exits 1)
── budget check, after the fixes : SQL queries per page 1 / 5 ✅ · LCP ms (simulated) 1055 / 2500 ✅ · page weight KB 452.5 / 500 ✅ · p95 ms at 70 req/s 23 / 100 ✅ → PASS

तुमचा snippet हे छापतो:

service 5 ms, 60 req/s → p95 22 ms
service 5 ms, 80 req/s → p95 25 ms
service 5 ms, 95 req/s → p95 28 ms
SQL queries per page: 7 / 5 OVER
page weight KB: 480 / 500 ok
FAIL
exit code: 1

पूर्ण demo ✅ done — every runner timed, the relay is faster ने संपतो, आणि tests 12/12 passed ने.

🏁 तुम्ही आत्ताच काय सिद्ध केले

50 वरून 90 requests/s (1.8× load) वर, p95 60 वरून 280 ms वर गेला (4.7×); 110/s वर, capacity च्या पलीकडे, तो 3 सेकंद ओलांडून गेला आणि तरीही वाढतच होता. Service time अर्धा केल्याने knee हलला: 95 requests/s वर p95 फक्त 28 ms होता. Budget ने "before" build ला चारही rows वर fail केले आणि "after" build pass केले. आणि मर्यादेपलीकडे गेलेली एकच row — 5 च्या budget विरुद्ध 7 queries — script ला exit 1 करायला पुरेशी होती, आणि CI job लाल होण्यासाठी एवढेच लागते.

⚠️ नेहमीच्या चुका

closed model ने load testing करून latencies खऱ्या users च्या असल्यासारख्या सांगणे
एकाच laptop वरून load testing, ज्याचे CPU किंवा connections server च्या आधीच संपतात
अगदी लहान database असलेल्या staging system वर test करणे — plans (धडा 10) आणि caches वेगळे असतात
फक्त mean सांगणारा load test (धडा 01)
shared CI runners वर घट्ट मर्यादांसह वेळेवर आधारित budgets — flaky builds, मग दुर्लक्षित builds
ज्याची जबाबदारी कोणाचीच नाही असा budget: तो fail झाला की code दुरुस्त करण्याऐवजी मर्यादा वाढवली जाते

🏭 प्रत्यक्ष वापरात

खऱ्या account वर — open-model executor आणि run fail करणाऱ्या thresholds सह k6 load test (threshold fail झाल्यास k6 non-zero exit करतो):

import http from 'k6/http';
export const options = {
  scenarios: { steady: { executor: 'constant-arrival-rate', rate: 70, timeUnit: '1s',
                         duration: '5m', preAllocatedVUs: 50, maxVUs: 200 } },
  thresholds: { http_req_duration: ['p(95)<100'], http_req_failed: ['rate<0.01'] },
};
export default function () { http.get('https://staging.results.school.example/results'); }

k6 run results-load.js

साध्या test सारखा query-count budget (Django):

class ResultsPageBudget(TestCase):
    def test_results_page_queries(self):
        make_runners(50)
        with self.assertNumQueries(2):        # fails if an N+1 sneaks back in
            self.client.get("/results/")

प्रत्येक pull request वर budgets चालवणारा GitHub Actions job, आणि page साठी Lighthouse CI:

name: performance-budgets
on: [pull_request]
jobs:
  budgets:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with: { python-version: "3.12" }
      - run: pip install -r requirements.txt
      - run: python manage.py test budgets          # query counts, response sizes
      - run: npx @lhci/cli autorun                  # LCP, bytes, CLS against lighthouserc.json assertions

🏭 प्रत्यक्ष वापरात हे का महत्त्वाचे: पुढच्या feature आधी budget लिहून ठेवा, count वर आधारित भाग आजच CI मध्ये घाला, आणि प्रत्येक मोठ्या कार्यक्रमाआधी तुमच्या सर्वात busy तासाच्या 1.5–2× वर load test चालवा. जिथे CI मध्ये वेळ तपासावी लागते, तिथे त्याच machine वरच्या baseline शी तुलना करा, किंवा त्याऐवजी CPU instructions मोजा (Cachegrind-आधारित tools हे करतात).

🎓 क्रीडा दिन संपला

स्टॉपवॉच mean नव्हे तर percentiles सांगतात → benchmark warm up होतो, पुनरावृत्ती करतो आणि त्याचा पसारा दाखवतो → प्रशिक्षिकेचा clipboard hot spot शोधतो → योग्य algorithm वक्र बदलतो → generators एका वेळी एकच अडथळा धरतात → scoreboard लक्षात ठेवतो, आणि त्याचा hit ratio किती ते सांगतो → प्रत्येक बॅटन-बदलाला एक फेरी लागते, म्हणून batch करा → वाट पाहणे overlap होते, Python कामाला बॅटन लागते → 100% busy जवळ पाण्याच्या टेबलावरची प्रतीक्षा स्फोटक वाढते, आणि सर्वात हळू टप्पा रिलेला मर्यादा घालतो → index 10,000 वाचण्याऐवजी 20 पत्रके शोधतो → page चे मूल्यमापन पालकांच्या phone वर होते → आणि CI मधील पात्रता वेळा हे सगळे वेगवान ठेवतात. तुम्ही फक्त performance च्या युक्त्या शिकल्या नाहीत — तुम्ही कोणताही हळू program घेऊन, तो मोजून, महत्त्वाची एकच गोष्ट शोधून, ती दुरुस्त करून, ती दुरुस्तच राहिली हे सिद्ध करू शकता. 🏎️🏆🎓

⏭️ पुढे

इतर शाळा. Scaling school एक machine पुरेशी नसेल तेव्हा machines जोडते; Observability school production मधले percentiles आणि traces गोळा करते; Database school queries मध्ये अधिक खोलवर जाते; DSA school algorithms मध्ये; School portal मध्ये बाकी सगळे आहे.

git checkout main
python3 perf/demo.py     # one last run, for fun

🏆 Lesson 12 — Load tests, budgets & the whole picture: qualifying times

📍 You are here: Lesson 12 of 12 · Previous: lesson-11-web-performance · The last lesson 🎓

📦 What's in this branch

Lessons 01–11, plus keeping it fast: a load test finds where latency bends under traffic (the knee), and a performance budget in CI fails the build when a change makes things worse — queries per page, bytes, LCP, p95. The lesson ends with the whole map of the course. budgets() in perf/demo.py and load_test and check_budget in perf/sim.py.

🧒 Explain like I'm 5

Before the real sports day, the school holds a rehearsal. 🏟️ They send more and more runners through the water table to see when it gets slow.

50 runners a second: fine, most wait a few moments.
70 a second: still fine for most, but the slow ones wait longer.
90 a second: the queue gets long.
110 a second: more than the table can handle. The queue just grows and grows. 😵

So now they know: stay well below 90.

Then Dipika writes qualifying times on the wall 📝: "The results page may use at most 5 trips to the office. It must appear in under 2.5 seconds. It may weigh at most 500 KB." Every time someone changes the results program, a helper checks the qualifying times. If the change breaks one, the helper says "no — try again" before sports day, not during it. ❌➡️✅

🗺️ Diagram

flowchart LR
    lt["🏟️ load test, open model<br/>10 ms a request"] --> r50["50/s → p95 60 ms"]
    r50 --> r70["70/s → p95 109 ms"]
    r70 --> r90["90/s → p95 280 ms"]
    r90 --> r110["110/s → p95 3122 ms<br/>above capacity"]
    b["📝 budget: queries ≤ 5 · LCP ≤ 2500 ms<br/>weight ≤ 500 KB · p95 ≤ 100 ms"] --> before["before: 51 · 5020 · 2210 · 109 → FAIL"]
    b --> after["after: 1 · 1055 · 452.5 · 23 → PASS"]

🗺️ Drawn version + a lab: https://school-edh.pages.dev/performance/lesson-diagrams.html#l12

❓ What

Load test — send a controlled amount of traffic and measure latency percentiles, errors and throughput. Kinds: load (expected traffic), stress (beyond it, to find the breaking point), spike (a sudden jump), soak (hours, to find leaks and slow growth).
The knee — the load where latency stops growing slowly and starts growing fast. In lesson 09's terms, it is where utilisation gets high. Plan to run below it.
Open vs closed model — an open load generator sends requests on a schedule, whatever the replies do (like real users arriving). A closed one waits for each reply before sending the next, so when the server slows down, the generator slows down too and the test sends less load than it claims. Gil Tene named the resulting measurement error coordinated omission. The lab's load test is open.
Performance budget — a limit that a change must not break: queries per page, page weight, bundle size, LCP in a lab test, p95 in a load test. A budget turns "it got slower over a year" into "this commit made it slower".
Counts vs times in CI — shared CI machines are noisy (lesson 02), so time-based checks there flake or need wide margins. Counts — queries, bytes, calls, allocations — are the same on every run, so they make strict, reliable gates. Timings belong on a quiet, fixed machine, compared against a stored baseline.

🤔 Why

Because performance decays quietly. Nobody adds an N+1 on purpose; it arrives in a small change that passed every functional test. A budget in CI catches it on the day it is written, when the fix is one line. And a load test before a big day tells you where the knee is while you still have time to move it.

🔧 How (in this repo)

load_test(rates, service_ms, n, seed) in perf/sim.py runs lesson 09's simulate_queue (one server, random arrivals, open model) at each rate and returns p50, p95 and p99. check_budget(measured, budget) compares each measurement with its limit and returns the rows and an overall pass/fail. budgets() in perf/demo.py measures the "before" values live from earlier lessons — the query count from lesson 07's N+1, LCP and bytes from lesson 11 — and the "after" values from their fixes. The "after" p95 assumes the profiled fix cut the service time from 10 ms to 5 ms: an input of the model.

🧪 Try it

python3 perf/demo.py budgets
python3 - <<'EOF'
import sys; sys.path.insert(0, "perf"); from sim import load_test, check_budget
for r, p50, p95, p99 in load_test((60, 80, 95), service_ms=5.0):
    print(f"service 5 ms, {r} req/s → p95 {p95} ms")
rows, ok = check_budget({"SQL queries per page": 7, "page weight KB": 480}, {"SQL queries per page": 5, "page weight KB": 500})
for name, value, limit, good in rows: print(f"{name}: {value} / {limit} {'ok' if good else 'OVER'}")
print("PASS" if ok else "FAIL")
sys.exit(0 if ok else 1)
EOF
echo "exit code: $?"
python3 perf/demo.py
python3 perf/test_perf.py

✅ Verify — what you should see

budgets prints:

── a load test (simulated, open model): one server, 10 ms per request, capacity about 100 requests/s
    50 req/s → p50    14 ms · p95    60 ms · p99    98 ms
    70 req/s → p50    25 ms · p95   109 ms · p99   160 ms
    90 req/s → p50    64 ms · p95   280 ms · p99   411 ms
   110 req/s → p50  1716 ms · p95  3122 ms · p99  3187 ms
   the knee: past about 80% busy, p95 climbs fast · above capacity the queue only grows
── budget check, before the fixes: SQL queries per page 51 / 5 ❌ · LCP ms (simulated) 5020 / 2500 ❌ · page weight KB 2210 / 500 ❌ · p95 ms at 70 req/s 109 / 100 ❌ → FAIL (the CI job exits 1)
── budget check, after the fixes : SQL queries per page 1 / 5 ✅ · LCP ms (simulated) 1055 / 2500 ✅ · page weight KB 452.5 / 500 ✅ · p95 ms at 70 req/s 23 / 100 ✅ → PASS

Your snippet prints:

service 5 ms, 60 req/s → p95 22 ms
service 5 ms, 80 req/s → p95 25 ms
service 5 ms, 95 req/s → p95 28 ms
SQL queries per page: 7 / 5 OVER
page weight KB: 480 / 500 ok
FAIL
exit code: 1

The full demo ends with ✅ done — every runner timed, the relay is faster, and the tests with 12/12 passed.

🏁 What you just proved

From 50 to 90 requests/s (1.8× the load), p95 went from 60 to 280 ms (4.7×); at 110/s, above capacity, it passed 3 seconds and was still climbing. Halving the service time moved the knee: at 95 requests/s, p95 was only 28 ms. The budget failed the "before" build on all four rows and passed the "after" one. And a single row over its limit — 7 queries against a budget of 5 — was enough to make the script exit 1, which is all a CI job needs to go red.

⚠️ Common mistakes

load testing with a closed model and reporting the latencies as if they were real users
load testing from one laptop, which runs out of CPU or connections before the server does
testing a staging system with a tiny database — the plans (lesson 10) and caches differ
a load test that only reports the mean (lesson 01)
time-based budgets on shared CI runners with tight limits — flaky builds, then ignored builds
a budget nobody owns: when it fails, the limit is raised instead of the code fixed

🏭 In production

On a real account — a k6 load test with an open-model executor and thresholds that fail the run (k6 exits non-zero when a threshold fails):

import http from 'k6/http';
export const options = {
  scenarios: { steady: { executor: 'constant-arrival-rate', rate: 70, timeUnit: '1s',
                         duration: '5m', preAllocatedVUs: 50, maxVUs: 200 } },
  thresholds: { http_req_duration: ['p(95)<100'], http_req_failed: ['rate<0.01'] },
};
export default function () { http.get('https://staging.results.school.example/results'); }

k6 run results-load.js

A query-count budget as a normal test (Django):

class ResultsPageBudget(TestCase):
    def test_results_page_queries(self):
        make_runners(50)
        with self.assertNumQueries(2):        # fails if an N+1 sneaks back in
            self.client.get("/results/")

A GitHub Actions job that runs the budgets on every pull request, and Lighthouse CI for the page:

name: performance-budgets
on: [pull_request]
jobs:
  budgets:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with: { python-version: "3.12" }
      - run: pip install -r requirements.txt
      - run: python manage.py test budgets          # query counts, response sizes
      - run: npx @lhci/cli autorun                  # LCP, bytes, CLS against lighthouserc.json assertions

🏭 Why this matters in production: write the budget down before the next feature, put the count-based parts in CI today, and run a load test at 1.5–2× your busiest hour before every big event. Where timing must be checked in CI, compare against a baseline on the same machine, or count CPU instructions instead (Cachegrind-based tools do this).

🎓 Sports day is over

The stopwatches report percentiles, not the mean → a benchmark warms up, repeats and shows its spread → the coach's clipboard finds the hot spot → the right algorithm changes the curve → generators hold one hurdle at a time → the scoreboard remembers, and its hit ratio says how much → every hand-off costs a trip, so batch → waiting overlaps, Python work needs the baton → the water table's wait explodes near 100% busy, and the slowest leg caps the relay → the index finds 20 sheets instead of reading 10,000 → the page is judged on a parent's phone → and qualifying times in CI keep it all fast. You didn't just learn performance tricks — you can take any slow program, measure it, find the one thing that matters, fix it, and prove it stayed fixed. 🏎️🏆🎓

⏭️ Next

The other schools. The Scaling school adds machines when one is not enough; the Observability school collects the percentiles and traces in production; the Database school goes deeper on queries; the DSA school on algorithms; the School portal has the rest.

git checkout main
python3 perf/demo.py     # one last run, for fun

← Previousweb performance Finished! Take the quiz →check what stuck

This page is the lesson's README from the lesson-12-load-testing-budgets branch, shown here so the whole School stays on one site. Code files open on GitHub at the same branch.