Measuring performance

📘What it really is

• Measure before you optimise. Most slowness comes from a few places, often not where you'd guess.
• Key measures:
• latency at percentiles (p50, p95, p99): the p95 is what your slower users feel;
• throughput: requests per second handled;
• error rate under load;

• saturation: CPU, memory, database connections, queue length (the four golden signals, Module 72).

• Load testing (on staging, never against production without planning):

• load test: expected peak traffic (the 7 to 10 pm rush);
• stress test: increase until something breaks, to find the limit and the first bottleneck;

• soak test: steady load for hours, to find memory leaks and slow build-ups.

• A k6 script:

import http from "k6/http";
import { check, sleep } from "k6";

export const options = {
  stages: [
    { duration: "2m", target: 100 },  // ramp up to 100 virtual users
    { duration: "5m", target: 100 },  // hold
    { duration: "1m", target: 0 },
  ],
  thresholds: { http_req_duration: ["p(95)<800"], http_req_failed: ["rate<0.01"] },
};

export default function () {
  const res = http.get("https://staging.example.in/v1/tutors?subject=maths");
  check(res, { "status is 200": (r) => r.status === 200 });
  sleep(1);
}

• Find the bottleneck: while testing, watch which resource saturates first: database CPU, slow queries (EXPLAIN ANALYZE, Module 57), connection pool limits, API CPU, an outside service. Fix that one, then test again; the bottleneck moves.

• Profiling (Node.js --cpu-prof, Chrome DevTools, clinic.js) shows where code spends time.

• Frontend performance matters too: bundle size, images, Core Web Vitals (Module 39); for many users on mobile networks in India, a smaller page is the biggest win.