← कोर्सच्या मुख्य पानाकडे परत

⏮️ आधी काय होते & फायदे-तोटे

प्रत्येक साधनाने काहीतरी वाईट गोष्ट बदलली — आणि तेच साधन कुठेतरी चुकीचे ठरते. प्रत्येक मोठ्या कल्पनेसाठी: आधी जीवन कसे होते, प्रामाणिक फायदे ✅ / तोटे ❌, आणि कुठे वापरावी 👍 विरुद्ध कुठे नाही 👎.

⏱️ The mean vs percentiles — lesson 01

⏮️ Percentiles आधी

One number — the average response time — on a dashboard, looking fine while some users waited seconds.

✅ फायदे

  • percentiles: show the typical case (p50) and the tail (p95, p99) separately
  • the mean: easy, and right for totals such as CPU seconds and cost

❌ तोटे

  • percentiles: need many samples and cannot be averaged across servers
  • the mean: pulled by a few huge values; can describe no real request

👍 वापरा जेव्हा

  • p50/p95/p99 on every latency chart and in every SLO
  • merge histograms before taking a percentile across instances

👎 दोनदा विचार करा जेव्हा

  • reporting only the mean latency
  • averaging each server's p99 into a 'global p99'

📋 Tracing (cProfile) vs sampling (py-spy, perf) profilers — lesson 03

⏮️ Before profilers

Guessing: adding print(time.time()) lines around the parts that 'looked slow'.

✅ फायदे

  • tracing: exact call counts and every function
  • sampling: low overhead, attaches to a running process, safe-ish in production

❌ तोटे

  • tracing: overhead inflates code with many tiny calls
  • sampling: estimates, can miss very short functions

👍 वापरा जेव्हा

  • cProfile on a test run to find the hot function and count calls
  • py-spy or perf on the real service under real load

👎 दोनदा विचार करा जेव्हा

  • cProfile times for micro-level decisions
  • sampling a process for one second and trusting the result

🗂️ Caching vs recomputing — lesson 06

⏮️ Before caching

Every request did all the work again, even for the same popular question.

✅ फायदे

  • a hit costs almost nothing; skewed traffic makes small caches useful
  • recomputing: always fresh, no memory, nothing to invalidate

❌ तोटे

  • a cache: stale data, memory, stampedes on expiry, cold starts
  • recomputing: repeats the same expensive work

👍 वापरा जेव्हा

  • pure functions (lru_cache), popular read-mostly data with a TTL
  • anything where a few seconds of staleness is fine

👎 दोनदा विचार करा जेव्हा

  • caching per-user data under shared keys
  • caching before profiling, or a cache nobody measures the hit ratio of

🔁 One query per row (N+1) vs batching — lesson 07

⏮️ Before batching

An ORM loop that looked like one line and ran one query per row — invisible with 3 test rows.

✅ फायदे

  • batching: one round trip for many items; the count stays flat as data grows
  • per-row queries: simple code, small memory per step

❌ तोटे

  • batching: bigger responses, limits on IN lists, more complex code
  • per-row: the round-trip toll N times; grows with the data

👍 वापरा जेव्हा

  • JOINs, IN (...) in chunks, select_related / prefetch_related / selectinload
  • bulk inserts with executemany or COPY

👎 दोनदा विचार करा जेव्हा

  • a query or HTTP call inside a loop over rows
  • one IN list with 100,000 values

🧵 Threads vs asyncio vs processes — lesson 08

⏮️ Before concurrency

One task at a time — the program sat idle while it waited for every reply.

✅ फायदे

  • threads/asyncio: overlap waiting cheaply
  • processes: real parallel CPU work on several cores
  • free-threaded CPython (3.13+): parallel threads without the GIL, where supported

❌ तोटे

  • threads: no CPU speed-up for pure Python with the GIL; shared-state bugs
  • asyncio: a blocking call stops everything
  • processes: start-up and pickling costs

👍 वापरा जेव्हा

  • threads or asyncio for I/O-bound work
  • processes for CPU-bound Python; native libraries that release the GIL

👎 दोनदा विचार करा जेव्हा

  • threads for pure-Python number crunching on the standard build
  • time.sleep or requests inside async code

🏆 Time budgets vs count budgets in CI — lesson 12

⏮️ Before budgets

Performance checked by hand before a big launch — and slowly lost, one small change at a time.

✅ फायदे

  • count budgets (queries, bytes, calls): the same on every run, strict and reliable
  • time budgets: measure what users feel

❌ तोटे

  • count budgets: miss slow-downs that do not change counts
  • time budgets: flaky on shared CI machines; need a quiet, fixed machine and a baseline

👍 वापरा जेव्हा

  • query counts, bundle sizes and page weight on every pull request
  • load tests and time comparisons on a dedicated machine, before big events

👎 दोनदा विचार करा जेव्हा

  • tight wall-clock limits on shared CI runners
  • a budget with no owner, raised whenever it fails