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

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

🩺 धडा 12 — Performance आणि operations: रेकॉर्ड रूम on call

📍 तुम्ही इथे आहात: 18 पैकी धडा 12 · मागील: lesson-11-nosql-other-rooms · पुढील: lesson-13-security

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

संपूर्ण कोर्स, आणि शेवटचा टप्पा: N+1 चा सापळा, slow-query log, महत्त्वाचे metrics, आणि इतर लोक ज्यावर अवलंबून आहेत अशा रेकॉर्ड रूमसाठी on-call चेकलिस्ट.

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

एका report ला प्रत्येक विद्यार्थी आणि त्याच्या श्रेणी हव्या आहेत. आळशी पद्धतीत अभिलेखपालाला यादीसाठी एक प्रश्न, मग प्रत्येक विद्यार्थ्यासाठी एक प्रश्न पाठवला जातो — पाच विद्यार्थ्यांसाठी सहा फेऱ्या, हजारासाठी एक हजार एक फेऱ्या. हेच N+1, आणि जगातले सर्वात सामान्य हळू page हेच आहे. उपाय म्हणजे एकच फेरी: एक JOIN (किंवा एक WHERE id IN (…)).

अशा गोष्टी users च्या आधी कशा शोधायच्या? अभिलेखपाल एक हळू-प्रश्नांची नोंदवही 🩺 ठेवते: N milliseconds पेक्षा जास्त वेळ घेतलेला प्रत्येक प्रश्न, त्याच्या मार्गासह (EXPLAIN). ती दर आठवड्याला वाचा; वरचे दहा म्हणजे तुमचे पुढचे दहा सुधार.

आणि खोली on call असताना, "ती निरोगी आहे का?" याचे उत्तर एक छोटी चेकलिस्ट कोणत्याही dashboard फेरीपेक्षा लवकर देते:

connections मर्यादेजवळ? · replication lag? · disk आणि log ची वाढ?
lock waits आणि deadlocks? · या आठवड्यातल्या सर्वात हळू दहा queries?
शेवटचा restore drill कधी झाला?

🗺️ आकृती

flowchart LR
    n1["🐢 N+1<br/>SELECT students; then SELECT grades WHERE student_id = ? × N"]
    one["🐇 one JOIN<br/>SELECT s.name, COUNT(g.id) … LEFT JOIN … GROUP BY s.id"]
    log["🩺 slow-query log<br/>every query > N ms, with its plan"]
    dash["📊 QPS · p95 latency · error rate · cache hit rate · connections · lag · disk"]
    n1 -->|"1 rewrite"| one
    log -->|"2 top ten weekly"| one
    dash -->|"3 alert on"| log

❓ काय

N+1: queries चा loop. JOIN, IN (…), किंवा ORM चे eager loading (select_related, includes, joinedload) वापरून सुधारा.
Slow-query log: log_min_duration_statement (Postgres), slow log (MySQL); code मध्ये, प्रत्येक query ची वेळ मोजा आणि मर्यादेपेक्षा जास्त असेल तर request id सह log करा (API school L12).
Metrics: queries per second, प्रत्येक query family साठी p95/p99 latency, error rate, cache hit ratio (buffer cache!), वापरलेले connections विरुद्ध max, replication lag, मोकळी disk, WAL size, lock waits, deadlocks. ज्यांच्यासाठी माणसाला page करावे लागते त्यांच्यावर alert लावा; बाकी dashboard वर ठेवा.
"Database हळू आहे" साठी तपासणीचा क्रम: काय बदलले (deploy, data वाढ)? → slow-query log → वरच्या query चा EXPLAIN → index किंवा rewrite → पुन्हा मोजा. मग शिडी (धडा 10).
देखभाल: vacuum/analyze (Postgres), statistics, index bloat, restore drill, credential rotation, version upgrades आधी एका copy वर.

🤔 का

कारण database install करून संपत नाही, तो चालवावा लागतो. जी team दर आठवड्याला slow log वाचते आणि दर तिमाहीला restore drill करते, तिचे on-call कंटाळवाणे असते; जी team दोन्हीपैकी काहीच करत नाही, ती दोन्ही outage मधून शिकते. चेकलिस्ट हाच सगळा फरक आहे.

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

db/demo.py मधले nplus1() loop आणि JOIN दोन्ही चालवते आणि दोन्हीची वेळ मोजते. school.db साठी चेकलिस्ट तुम्ही लिहायची आहे — छोट्या खोल्यांनाही तेच प्रश्न लागतात, फक्त लहान प्रमाणात.

🧪 करून पाहा — capstone

python3 db/demo.py nplus1
python3 - <<'EOF'
import sqlite3, time
c = sqlite3.connect("db/school.db")
# 1) a slow-query log in 6 lines
def q(sql, *a, threshold_ms=0.05):
    t=time.perf_counter(); rows=c.execute(sql, a).fetchall(); ms=(time.perf_counter()-t)*1000
    if ms > threshold_ms: print(f"🐢 {ms:.3f} ms · {sql[:60]} · plan: {c.execute('EXPLAIN QUERY PLAN '+sql, a).fetchall()[0][3]}")
    return rows
q("SELECT COUNT(*) FROM attendance WHERE day = '2026-03-03'")          # a candidate for the log
q("SELECT COUNT(*) FROM attendance WHERE student_id = 4242")           # served by lesson 06's index
# 2) the checklist, measured:
print("rows:", c.execute("SELECT COUNT(*) FROM attendance").fetchone()[0], "· page_size:", c.execute("PRAGMA page_size").fetchone()[0], "· journal:", c.execute("PRAGMA journal_mode").fetchone()[0])
EOF
# 3) capstone: add a teachers table (L05), a migration for it (L08), an index a new question needs (L06),
#    a query that would be N+1 written as one JOIN, and a one-page on-call checklist for school.db.

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

nplus1 एकाच उत्तरासाठी 6 queries विरुद्ध 1 दाखवते; तुमचा slow-query log day query SCAN plan सह छापतो (index साठी उमेदवार) आणि index असलेल्या student_id query साठी गप्प राहतो. चेकलिस्ट खऱ्या file साठी खरे आकडे छापते.

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

तुम्ही हळू प्रश्न शोधू शकता, त्याचा मार्ग वाचू शकता, एका JOIN ने किंवा एका index ने तो सुधारू शकता, आणि खोली निरोगी आहे का हे — आकड्यांसह — सांगू शकता.

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

सुंदर code मागे N+1 लपवणारे ORM loops — प्रत्येक request मागे query count log करा
प्रत्येक गोष्टीवर alert (किंवा कशावरच नाही) — माणसाने आत्ता कृती करावी अशा गोष्टींवरच page करा
अंदाजाने tuning — आधी नेहमी slow log आणि EXPLAIN
"काहीच बदलले नाही" म्हणून restore drill विसरणे
copy वर सराव न करता चालू खोलीवर database version upgrade करणे

🏭 प्रत्यक्ष वापरात हे का महत्त्वाचे: database on call जाण्याआधी reviewers हीच चेकलिस्ट वापरतात: slow log चालू, p95 आणि lag असलेले dashboards, connection limits आणि pooling, drill च्या तारखेसह backups, CI मध्ये migrations. एक चुकले तरी तेच incident बनते.

🎓 रेकॉर्ड रूम आता तुमची — भाग 3 अधिक खोलात जातो

खोली चालू आहे. भाग 3 (धडे 13–18) interviews आणि incidents मध्ये विचारले जाणारे प्रश्न उघडतो: git checkout lesson-13-security.

तुम्ही कुठून कुठे आलात

चिकट चिठ्ठ्या → रेकॉर्ड रूम → नोंदवह्या आणि keys → अभिलेखपालाला प्रश्न विचारणे → पेन्सिलमधली नोंदवही → एक तथ्य, एक जागा → कार्ड कॅटलॉग → दोन कारकून, एक नोंदवही → चालू असतानाच नूतनीकरण → आगीपासून सुरक्षित प्रत → अधिक कारकून, अधिक खोल्या → इतर खोल्या → on call. तुम्ही फक्त databases शिकल्या नाहीत — तुम्ही एक चालवता. 🗄️🎓

शाळेतले पुढचे दरवाजे: API शाळा या खोलीसमोर एक counter ठेवते; VectorDB शाळा शेजारचे अर्थाचे सभागृह उघडते.

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

🩺 Lesson 12 — Performance & operations: the record room on call

📍 You are here: Lesson 12 of 18 · Previous: lesson-11-nosql-other-rooms · Next: lesson-13-security

📦 What's in this branch

The complete course, plus the last mile: the N+1 trap, the slow-query log, the metrics that matter, and the on-call checklist for a record room that other people depend on.

🧒 Explain like I'm 5

A report needs every student and their grades. The lazy way sends the archivist one question for the list, then one question per student — six trips for five students, a thousand and one trips for a thousand. That is N+1, and it is the most common slow page in the world. The fix is one trip: a JOIN (or one WHERE id IN (…)).

How do you find such things before users do? The archivist keeps a slow-question log 🩺: every question that took longer than N milliseconds, with its route (EXPLAIN). Read it weekly; the top ten are your next ten fixes.

And when the room is on call, a short checklist answers "is it healthy?" faster than any dashboard tour:

connections near the limit? · replication lag? · disk and log growth?
lock waits and deadlocks? · the slowest ten queries this week?
when was the last restore drill?

🗺️ Diagram

flowchart LR
    n1["🐢 N+1<br/>SELECT students; then SELECT grades WHERE student_id = ? × N"]
    one["🐇 one JOIN<br/>SELECT s.name, COUNT(g.id) … LEFT JOIN … GROUP BY s.id"]
    log["🩺 slow-query log<br/>every query > N ms, with its plan"]
    dash["📊 QPS · p95 latency · error rate · cache hit rate · connections · lag · disk"]
    n1 -->|"1 rewrite"| one
    log -->|"2 top ten weekly"| one
    dash -->|"3 alert on"| log

❓ What

N+1: a loop of queries. Fix with JOIN, IN (…), or the ORM's eager loading (select_related, includes, joinedload).
Slow-query log: log_min_duration_statement (Postgres), the slow log (MySQL); in code, time every query and log over a threshold with the request id (API school L12).
Metrics: queries per second, p95/p99 latency per query family, error rate, cache hit ratio (buffer cache!), connections used vs max, replication lag, disk free, WAL size, lock waits, deadlocks. Alert on the ones that page a human; dashboard the rest.
Triage order for "the database is slow": what changed (deploy, data growth)? → slow-query log → EXPLAIN the top one → index or rewrite → measure again. Then the ladder (lesson 10).
Maintenance: vacuum/analyze (Postgres), statistics, index bloat, the restore drill, credential rotation, version upgrades on a copy first.

🤔 Why

Because a database is operated, not installed. The team that reads the slow log weekly and drills a restore quarterly has boring on-call; the team that does neither learns both from an outage. The checklist is the whole difference.

🔧 How (in this repo)

nplus1() in db/demo.py runs the loop and the JOIN and times both. The checklist is yours to write for school.db — small rooms need the same questions, on a smaller scale.

🧪 Try it — the capstone

python3 db/demo.py nplus1
python3 - <<'EOF'
import sqlite3, time
c = sqlite3.connect("db/school.db")
# 1) a slow-query log in 6 lines
def q(sql, *a, threshold_ms=0.05):
    t=time.perf_counter(); rows=c.execute(sql, a).fetchall(); ms=(time.perf_counter()-t)*1000
    if ms > threshold_ms: print(f"🐢 {ms:.3f} ms · {sql[:60]} · plan: {c.execute('EXPLAIN QUERY PLAN '+sql, a).fetchall()[0][3]}")
    return rows
q("SELECT COUNT(*) FROM attendance WHERE day = '2026-03-03'")          # a candidate for the log
q("SELECT COUNT(*) FROM attendance WHERE student_id = 4242")           # served by lesson 06's index
# 2) the checklist, measured:
print("rows:", c.execute("SELECT COUNT(*) FROM attendance").fetchone()[0], "· page_size:", c.execute("PRAGMA page_size").fetchone()[0], "· journal:", c.execute("PRAGMA journal_mode").fetchone()[0])
EOF
# 3) capstone: add a teachers table (L05), a migration for it (L08), an index a new question needs (L06),
#    a query that would be N+1 written as one JOIN, and a one-page on-call checklist for school.db.

✅ Verify — what you should see

nplus1 shows 6 queries vs 1 with the same answer; your slow-query log prints the day query with a SCAN plan (a candidate for an index) and stays silent for the indexed student_id query. The checklist prints real numbers for a real file.

🏁 What you just proved

You can find the slow question, read its route, fix it with one JOIN or one index, and say — with numbers — whether the room is healthy.

⚠️ Common mistakes

ORM loops that hide N+1 behind pretty code — log query counts per request
alerting on everything (or nothing) — page on what a human must act on now
tuning by guesswork — the slow log and EXPLAIN first, always
forgetting the restore drill because "nothing changed"
upgrading the database version on the live room without a rehearsal on a copy

🏭 Why this matters in production: this is the checklist reviewers use before a database goes on call: slow log on, dashboards with p95 and lag, connection limits and pooling, backups with a drill date, migrations in CI. Miss one and it becomes the incident.

🎓 The record room is yours — Part 3 goes deeper

The room runs. Part 3 (lessons 13–18) opens the questions interviews and incidents ask: git checkout lesson-13-security.

Where you have been

Sticky notes → the record room → registers and keys → asking the archivist → the ledger in pencil → one fact, one place → the card catalogue → two clerks, one register → renovating while open → the fireproof copy → more clerks, more rooms → other rooms → on call. You didn't just learn databases — you run one. 🗄️🎓

Next doors in the school: the API school puts a counter in front of this room; the VectorDB school opens the meaning hall next door.

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

← Previousnosql other rooms Next →security

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