Skip to content

Day 161 — Week 3 review + recall

Month 6 · Week 3 · ⬅ Day 160 · Day 162 ➡ · Journal index

🎯 Learning Objective

Consolidate the week's performance-and-hardening thread — profile → cut allocations → pool → load test → scan → harden — and prove retention with active recall.

📚 Topics

  • pprof (CPU sample / heap snapshot) · escape analysis · sync.Pool
  • Load testing percentiles · govulncheck/gosec · AuthN/Z + rate limiting

📖 Reading / Sources

📝 Notes

  • Light consolidation day; the full retro, re-quiz, and metrics live in the week review.
  • One-line thread: measure before you optimize, then optimize bottom-up — profile to find the cost, escape analysis to eliminate allocations, pool what's left, prove it under realistic load, and harden the surface (scan + auth + rate limit) so it survives contact with the internet.

💻 Code Examples

// The week's optimization order, as a checklist in code comments:
//   1. pprof:   where is the CPU/heap going?        runtime/pprof, net/http/pprof
//   2. -gcflags=-m: which allocations escape?       fix → stack, or append-into-buffer
//   3. sync.Pool: recycle the unavoidable ones      Reset after Get, pointers only
//   4. k6/vegeta: does it hold at target RPS @ p99?  open model, watch the knee
//   5. govulncheck + gosec: is it safe to ship?      reachable CVEs + insecure patterns
//   6. authn/z + rate limit: will it survive abuse?  401/403/429, constant-time compare

Runnable: examples/month-06/pprof · escape · syncpool · ratelimit

🏋️ Exercises / Practice

Exercise Status Link
tokenbucket · allocfree · bufpool (all go test green) ✅ exercises/month-06/week-3/

🐛 Mistakes Made

  • Early in the week I reached for sync.Pool before profiling. The right order is measure first — most "optimizations" without a profile are guesses.

❓ Open Questions

  • How do profiling-driven optimizations interact with the capstone's real bottleneck (DB/network) next week? → Month 6 Week 4.

🧠 Active Recall (answer without looking)

  1. Q: Put the week's six steps in order and name the key tool for each.
    A

(1) Profile — runtime/pprof + go tool pprof (CPU sample, heap snapshot). (2) Cut allocations — escape analysis via -gcflags=-m, append-into-buffer. (3) Recycle — sync.Pool (Reset after Get). (4) Load test — k6/vegeta, report p95/p99 at the knee. (5) Scan — govulncheck (reachable CVEs) + gosec (insecure patterns). (6) Harden — AuthN/Z + token-bucket rate limiting, constant-time compares.

  1. Q: Two "measure, don't guess" traps from this week?
    A

(1) Benchmarks reporting 0 allocs because dead-code elimination deleted unused results — consume the value via a sink. (2) Load tests flattering the tail via coordinated omission — use an open/arrival-rate model and report percentiles, not the mean.

🪶 Feynman Reflection

This week was the discipline of evidence-driven performance and security. Every step starts with a measurement (a profile, a percentile, a scan result) and ends with a change you can re-measure. Guessing at hot spots, sprinkling pools, or trusting averages all fail the same way: they optimize something that wasn't the problem.

🕳️ Knowledge Gaps

✅ Summary

Week 3 done: I can profile a Go service, eliminate and recycle allocations, prove behavior under realistic load, scan for vulnerabilities, and harden auth + rate limiting — all measurement-first.

⏭️ Next Steps / Prep for Tomorrow

  • Month 6 · Week 4: the capstone — assemble everything (architecture, API, persistence, cache, observability) into one production service.
Time spent Difficulty Confidence
75 min 🟦⬜⬜⬜⬜ 🟦🟦🟦🟦⬜

Suggested commit: docs(journal): week 3 review + recall (day 161)