“Tối ưu hiệu năng” dễ biến thành cảm tính kỹ sư: đổi thư viện, thêm index, bật cache — rồi P99 vẫn xấu vì bottleneck thật nằm chỗ khác. Middle+ cần quy trình giống thử nghiệm khoa học: giả thuyết có thể bác bỏ, đo có kiểm soát, kết luận có phạm vi.

Phạm vi: ứng dụng server và batch; không hướng dẫn từng profiler UI. Không thay thế: bài Logs, Metrics, Traces — đọc song song để biết tam giác quan sát.

1. Triệu chứng ≠ nguyên nhân gốc

Ví dụ: “API chậm”.

  • Triệu chứng: latency P99 cao.
  • Nguyên nhân có thể là: CPU nóng trên pod, chờ lock, query DB, remote dependency, GC, network policy, DNS, disk I/O log đồng bộ, hoặc queue chờ thread pool.

Nếu không phân loại, bạn sẽ “tối ưu code hot path” trong khi thực tế đang chờ I/O.

2. Phân loại bottleneck (khung làm việc)

2.1. CPU-bound

  • Dấu hiệu: CPU utilization cao, flame graph dày ở user code hoặc thư viện tính toán.
  • Hành động: thuật toán, allocation, parallelization có kiểm soát.

2.2. I/O-bound (disk/network)

  • Dấu hiệu: CPU thấp nhưng latency cao; span chờ DB/HTTP dài.
  • Hành động: batch query, connection pool, giảm round-trip, async có ý thức về backpressure.

2.3. Lock / contention

  • Dấu hiệu: throughput không tăng khi scale thread; profile có wait time.
  • Hành động: giảm critical section, lock-free có chứng cứ, hoặc chia partition dữ liệu.

2.4. Remote dependency

  • Dấu hiệu: error/latency theo downstream; retry làm trầm trọng.
  • Hành động: timeout, circuit breaker, cache có TTL — nhưng đo trước khi cache che giấu bug downstream.

2.5. GC / runtime (tuỳ ngôn ngữ)

  • Dấu hiệu: pause, allocation rate cao.
  • Hành động: giảm allocation, pooling có cân nhắc, tune VM — sau khi chứng minh.

3. Phương pháp chứng minh

  1. Metrics: throughput, latency histogram, saturation (CPU, pool), errors — xem 012.
  2. Traces: một request đi qua đâu, span nào chiếm thời gian.
  3. Sampling profiler (CPU): flame graph cho “ai ăn CPU”.
  4. Wall-clock / async profiler: chờ I/O, lock wait.

4. Sai lầm khi đo (đọc để tránh)

Sai lầmHệ quả
Đo trên laptop dev với dataset nhỏKết luấn “O(n) ok” trong khi prod O(n) trên n lớn
Bật profiler nặng liên tục trong prodOverhead làm thay đổi hành vi (Heisenberg)
Chỉ nhìn mean latencyMean che giấu đuôi dài; cần P95/P99
Tối ưu cold start khi P99 là query DBLãng phí sprint

5. Template báo cáo một trang (dán vào ticket/incident)

1) Giả thuyết: (một câu, có thể sai)
2) Chứng cứ:
   - Metrics: ...
   - Trace ví dụ (trace id): ...
   - Profile snapshot (thời điểm, môi trường): ...
3) Kết luận: bottleneck loại (CPU/I/O/lock/remote/…)
4) Thay đổi đề xuất + diff nhỏ nhất
5) Rủi ro rollback / feature flag / canary
6) Xác minh sau deploy: query/metric nào phải đổi thế nào

Nếu không điền được mục 2 bằng số liệu, bạn đang viết fiction.

Khi không nên profiling sâu

  • Incident đang cháy ưu tiên mitigate (rollback, scale, kill-switch) trước; profiling sau.
  • Vấn đề rõ là cấu hình (pool size = 1) — sửa config trước, đừng flame graph một tuần.

6. USE method áp vào một service HTTP (ví dụ)

Gregg đề xuất nhìn Utilization, Saturation, Errors cho mỗi tài nguyên. Với service API:

  • CPU: utilization cao nhưng saturation (queue depth) thấp → có thể vẫn ổn; utilization thấp nhưng latency cao → nghi I/O hoặc chờ lock.
  • Network: errors (RST, timeout) vs saturation (bandwidth, queue NIC).
  • Disk: log sync fsync — đôi khi là thủ phạm P99 bị bỏ quên khi mọi người chỉ nhìn “query DB”.

Giải thích thêm: “resource” không chỉ là hardware; thread pool, connection pool, semaphore cũng là tài nguyên có saturation.

7. Baseline và so sánh A/B có kiểm soát

Trước khi tối ưu, chụp baseline cùng điều kiện tải (RPS, payload, cache warm). Sau thay đổi:

  • So sánh P50/P95/P99, không chỉ mean.
  • Kiểm tra error rate và CPU per request — đôi khi code nhanh hơn nhưng allocation nhiều hơn làm GC tệ hơn trên tải lớn.

Canary 10% traffic với feature flag (xem 020) là cách giảm rủi ro khi không chắc tối ưu “luôn thắng”.

8. Case study ngắn: “P99 cao nhưng CPU thấp”

Giả thuyết ban đầu (sai): thuật toán trong handler phức tạp.

Chứng cứ: trace cho thấy span DB < 5ms nhưng tổng request 800ms; middleware logging đồng bộ tới remote syslog bị block; pool thread nhỏ nên request xếp hàng.

Thay đổi: async logging + tăng pool (có giới hạn) + circuit cho syslog.

Bài học: wall-time ≠ CPU-time; profiler CPU có thể không chỉ đúng chỗ nếu bottleneck là chờ I/O logging.

9. Checklist “đủ bằng chứng để merge tối ưu”

  • Có trace/metric trước và sau (hoặc canary so sánh).
  • Giải thích vì sao thay đổi không làm tệ hóa worst-case (ví dụ thêm lock).
  • Có rollback plan (flag, config revert).
  • Load test nhỏ hoặc shadow traffic nếu thay đổi nhạy.

10. FAQ

Hỏi: Có nên profile trên staging?

Đáp: Có giá trị cho tương đối và cho regression; nhưng số tuyệt đối vẫn khác prod (dữ liệu, traffic mix). Dùng staging để so sánh commit, prod để xác nhận giả thuyết về dữ liệu thật.

Hỏi: Continuous profiler trong prod?

Đáp: Hữu ích nếu sampling thấp và chi phí chấp nhận được; vẫn cần quy tắc redact PII trong stack trace.

Bài tập ngắn

Lấy một endpoint P99 cao: viết báo cáo theo template trên trước khi sửa code — sau đó mới mở profiler. So sánh giả thuyết ban đầu với chứng cứ.

Thêm: In một flame graph (hoặc trace waterfall) và gắn nhãn một span chiếm >30% thời gian — giải thích bằng một đoạn văn cho PM không đọc code.

11. Regression hiệu năng: biểu đồ trend 4 tuần

Một PR có thể làm tăng allocation 5% — không ai nhận ra trong một ngày, nhưng trend 4 tuần lộ ra. Giữ chart:

  • P99 endpoint top N.
  • GC pause (nếu có).
  • DB pool wait time.

Giải thích thêm: profiling không chỉ là hoạt động “một lần khi cháy”; nó là kiểm soát thay đổi giống như unit test cho hiệu năng.

12. Đồng bộ I/O ẩn: logging, metrics, trace exporter

Exporter telemetry đôi khi block hoặc buffer đầy → latency tăng. Khi trace cho thấy CPU thấp nhưng wall time cao, hãy kiểm:

  • batch size exporter,
  • disk flush,
  • DNS resolve cho collector.

Đây là lớp hay bị bỏ qua vì không nằm trong “business code”.

13. Micro-benchmark: khi nào hữu ích

Micro-benchmark tốt cho so sánh hai thuật toán trên cùng input cố định; nó không thay thế profiling trên workload thật. Quy tắc: nếu micro-benchmark nói “nhanh hơn 30%” nhưng canary prod không đổi P99, hãy nghi allocation/GC hoặc lock nằm ngoài đoạn code benchmark.

14. Checklist đọc flame graph (60 giây)

  1. Tìm plateau rộng (nhiều thời gian tích luỹ).
  2. Hỏi: đó là thư viện chuẩn hay code team?
  3. Nếu là thư viện: có phiên bản đã fix regression không?
  4. Nếu là code team: có I/O ẩn trong hàm “tính toán” không?

Tóm tắt cho người vội

  • Đo trước, đo sau; giả thuyết phải có thể bác bỏ.
  • CPU thấp + latency cao → nghi I/O, lock, pool, logging.
  • Template một trang giữ discipline khi incident.

Đọc thêm