Tối ưu hiệu năng là công việc thực nghiệm. Endpoint chậm không chứng minh hàm phức tạp nhất bên trong nó chậm; CPU bận cũng không chứng minh thêm CPU là lời giải. Độ trễ có thể đến từ hàng đợi, garbage collection, database, I/O hoặc một dạng input hiếm chi phối phần đuôi.

Một cuộc điều tra hữu ích nối bốn điểm: triệu chứng phía người dùng, workload lặp lại được, bằng chứng về nơi tiêu tốn tài nguyên và thay đổi vẫn hiệu quả dưới tải thực tế. Ta sẽ xây quy trình đó quanh Node.js và TypeScript.

Bắt đầu bằng phân phối độ trễ, không phải một giá trị trung bình

Giá trị trung bình nén cả quần thể vào một số. Nếu 99 request mất 20 ms và một request mất 2 giây, mean xấp xỉ 40 ms nhưng không mô tả trường hợp nào. p50 thể hiện trung vị, p95 cho thấy nhóm chậm hơn, còn p99 làm lộ lần khựng hiếm.

Với dãy quan sát x đã sắp xếp, percentile theo phương pháp nearest-rank có thể tính như sau:

rank=ceil((p/100)∗N)rank = ceil((p / 100) * N)
percentilep=x[rank−1]percentile_p = x[rank - 1]

Các nhãn rank, p, N, percentile_p dùng ASCII để chuyển nguyên vẹn vào dashboard. Cần ghi cả throughput và lỗi; hệ thống có thể cải thiện p50 bằng cách từ chối request đắt đỏ.

throughput=completedrequests/elapsedsecondsthroughput = completed_requests / elapsed_seconds
Tín hiệu Cho biết Dễ đọc sai thành
p50 Request điển hình Toàn bộ quần thể
p95/p99 Mức nghiêm trọng của đuôi chậm Kết luận từ mẫu nhỏ
Throughput Công việc hoàn thành mỗi giây Thành công dù lỗi tăng
CPU Năng lực tính toán đang bận Chính xác hàm gây chậm
RSS và heap Bộ nhớ giữ lại hoặc dành trước Mọi RSS lớn đều là leak
Event-loop delay Callback có chạy kịp không CPU cao dù synchronous I/O chặn

Hãy tách theo route, status, payload, tenant, cache, database shard và phiên bản. p99 toàn cục có thể che một loại báo cáo luôn chậm. Chỉ so cửa sổ tương đương và tính warm-up vì JIT, kết nối và cache làm méo phép đo lạnh.

Warning

Đừng công bố kết quả benchmark nếu thiếu workload, concurrency, hình dạng dữ liệu, phiên bản runtime, giới hạn phần cứng, chính sách warm-up và độ bất định. Một con số chính xác nhưng thiếu điều kiện không phải bằng chứng có thể tái lập.

Dựng baseline và kiểm tra từng giả thuyết

Viết phát biểu trước khi sửa mã: “Với báo cáo trên 100.000 event, filter lặp tiêu thụ phần lớn CPU; gom nhóm một lần sẽ giảm p95 mà không tăng peak heap quá 20%.” Đây là workload, cơ chế và guardrail có thể kiểm tra.

Baseline phải tái hiện triệu chứng ở quy mô thực tế nhỏ nhất. Giữ cardinality, phân phối key, kích thước object, cache hit ratio, concurrency và độ trễ downstream đại diện. Chạy đủ mẫu để thấy variance và lưu dữ liệu thô.

flowchart LR A[Xác định triệu chứng phía người dùng] --> B[Thu workload đại diện] B --> C[Đo độ trễ, throughput, lỗi, tài nguyên] C --> D[Profile tài nguyên bị giới hạn] D --> E[Lập một giả thuyết có thể bác bỏ] E --> F[Thực hiện thay đổi nhỏ nhất đúng mục tiêu] F --> G[Lặp lại trong cùng điều kiện] G --> H{Tốt hơn và guardrail còn nguyên?} H -->|Không| D H -->|Có| I[Canary và theo dõi production] I --> J[Thêm bảo vệ chống regression]

Nên xen kẽ baseline và candidate trên cùng máy để giảm drift, rồi báo cáo phân phối qua nhiều vòng. Một nhãn effect size hữu ích là:

speedup=baselinetime/candidatetimespeedup = baseline_time / candidate_time

speedup = 1.0 nghĩa là không đổi; 2.0 nghĩa là candidate mất nửa thời gian. Với hệ thống nhiễu, ghi confidence interval hoặc ít nhất min, median, p95 và số mẫu; không chọn riêng lượt tốt nhất.

Instrumentation đặt timer hoặc counter quanh thao tác đã biết, cho context chính xác nhưng thêm overhead. Sampling định kỳ ghi stack, nhẹ hơn và tìm được hot path bất ngờ, song có thể bỏ lỡ lời gọi ngắn. Chúng bổ sung chứ không thay thế nhau.

Phương pháp Phù hợp với Giới hạn
Metrics, tracing Route, dependency, phase Tổng hợp che chi phí cục bộ
Timer thủ công Một boundary cụ thể Overhead, sót việc lồng nhau
CPU sampling Hot stack on-CPU Sample chỉ là ước lượng
Allocation/heap Churn và object bị giữ Capture có thể đắt
Công cụ I/O Disk, network, scheduler Cần quyền host và correlation

Benchmark và profile một báo cáo Node.js/TypeScript

Xét báo cáo đếm event cho từng user. Bản đầu quét toàn bộ event riêng cho mỗi user. filter trông gọn nhưng công việc tăng theo O(user_count * event_count).

ts
import { performance } from 'node:perf_hooks';

type Event = { userId: number; bytes: number };
type Row = { userId: number; events: number; bytes: number };

function repeatedScan(events: readonly Event[], userIds: readonly number[]): Row[] {
  return userIds.map((userId) => {
    const matches = events.filter((event) => event.userId === userId);
    return {
      userId,
      events: matches.length,
      bytes: matches.reduce((sum, event) => sum + event.bytes, 0),
    };
  });
}

function groupedScan(events: readonly Event[], userIds: readonly number[]): Row[] {
  const totals = new Map<number, { events: number; bytes: number }>();

  for (const event of events) {
    const current = totals.get(event.userId) ?? { events: 0, bytes: 0 };
    current.events += 1;
    current.bytes += event.bytes;
    totals.set(event.userId, current);
  }

  return userIds.map((userId) => ({
    userId,
    events: totals.get(userId)?.events ?? 0,
    bytes: totals.get(userId)?.bytes ?? 0,
  }));
}

const userIds = Array.from({ length: 2_000 }, (_, userId) => userId);
const events = Array.from({ length: 200_000 }, (_, index) => ({
  userId: (index * 17) % userIds.length,
  bytes: 200 + (index % 800),
}));

let checksum = 0;

function measure(name: string, report: () => Row[]): void {
  const samples: number[] = [];
  for (let round = 0; round < 12; round += 1) {
    const started = performance.now();
    const rows = report();
    const elapsed = performance.now() - started;
    checksum += rows[round % rows.length]!.bytes;
    if (round >= 2) samples.push(elapsed); // bỏ hai vòng warm-up
  }

  samples.sort((left, right) => left - right);
  const p50 = samples[Math.floor(samples.length * 0.5)]!;
  const p95 = samples[Math.min(samples.length - 1, Math.floor(samples.length * 0.95))]!;
  console.log({ name, p50Ms: p50.toFixed(1), p95Ms: p95.toFixed(1) });
}

measure('repeated', () => repeatedScan(events, userIds));
measure('grouped', () => groupedScan(events, userIds));
console.log({ checksum });

Biên dịch TypeScript rồi chạy benchmark và CPU profile. Node ghi .cpuprofile để mở bằng Chrome DevTools hoặc editor:

bash
node --cpu-prof --cpu-prof-name=report.cpuprofile dist/profile-report.js
node --heap-prof --heap-prof-name=report.heapprofile dist/profile-report.js

Checksum ngăn benchmark phép tính có output không được dùng. Dữ liệu tất định giúp hai bản nhận cùng input. Khi đo nghiêm túc, chạy mỗi implementation trong process riêng, xáo trộn thứ tự, cố định runtime và giới hạn CPU, rồi thu nhiều vòng. Ví dụ chạy nối tiếp chỉ để chẩn đoán gọn.

Note

Microbenchmark chứng minh cơ chế, không chứng minh tác động phía người dùng. Sau khi thấy thuật toán gom nhóm loại bỏ các lượt quét lặp, vẫn phải kiểm tra toàn bộ request path với concurrency, serialization, hành vi database và network backpressure thực tế.

Đọc flamegraph và phân loại tài nguyên đang bị giới hạn

Flamegraph tổng hợp stack được sampling. Chiều rộng gần tương ứng thời gian on-CPU; chiều dọc là độ sâu lời gọi, không phải thời gian. Màu thường chỉ để phân biệt. Hãy tìm plateau rộng và caller, nhưng đừng mặc định tối ưu leaf rộng nhất vì nó có thể là runtime primitive cần thiết.

Một bản biểu diễn bằng chữ có tính đại diện cho baseline có thể như sau:

text
(root)                                      100%
  main                                       97%
    measure                                  95%
      repeatedScan                           88%
        Array.map                            87%
          Array.filter                       63%
          Array.reduce                       19%
      groupedScan                             5%
        Map.get / Map.set                      3%

repeatedScan và các lượt duyệt lồng chi phối sample. Profile ủng hộ giả thuyết công việc lặp, không chứng minh Array.filter luôn chậm. Vòng lặp viết tay vẫn giữ độ phức tạp xấu; bản sửa phải đổi nhiều lượt quét thành một lượt gom nhóm.

CPU chỉ là một lớp tài nguyên. Dùng bằng chứng để chọn profiler tiếp theo:

Mẫu quan sát Khả năng Bằng chứng tiếp theo
Stack rộng, một core bão hòa CPU CPU profile, deoptimization data
CPU thấp, database/HTTP span dài Chờ I/O Trace, pool wait, dependency metrics
Heap tăng sau full GC Retention/leak Snapshot, dominator path
Heap răng cưa, pause dày Churn/GC Allocation profile, GC trace
Event-loop delay và frame đồng bộ Main thread bị chặn Delay và CPU profile
Latency vọt theo concurrency Queue/contention Load curve, pool/lock metrics

Bộ nhớ có hai kiểu lỗi. Retention giữ object reachable, làm mức sàn sau GC tăng. Churn tạo object sống ngắn; heap trở về baseline nhưng collection vẫn tốn CPU và tạo pause. process.memoryUsage() cho xu hướng, heap snapshot cho biết object giữ bộ nhớ. Chỉ so snapshot ở phase tương đương.

Với I/O, trace nên tách pool wait, DNS/TLS, thực thi server, truyền response và decode. CPU profile có thể gần trống khi request chậm vì thời gian ngủ không phải on-CPU.

Kiểm thử tải toàn hệ thống, gồm GC và cơ sở dữ liệu

Load test phải tạo đường cong. Tăng offered concurrency theo nấc và ghi throughput hoàn thành, lỗi, percentile, CPU, bộ nhớ, event-loop delay, connection pool và downstream saturation. Dừng trước ngưỡng gây sự cố ở môi trường dùng chung.

Little’s Law là phép kiểm tra nhất quán hữu ích cho hệ thống ổn định:

concurrency=throughput∗latencyconcurrency = throughput * latency

Nếu throughput là request mỗi giây, latency phải tính bằng giây. Khi throughput đứng yên nhưng latency tăng, hàng đợi đang dài ra. Coordinated omission che hiện tượng này khi load generator đợi response rồi mới gửi tiếp; công cụ tốt phải giữ lịch arrival dự kiến và báo lượt bắt đầu trễ.

GC cần correlation. Chỉ dùng --trace-gc trong môi trường kiểm soát, đối chiếu major collection với spike độ trễ và allocation profile. Tăng heap limit có thể giảm tần suất collection nhưng tăng worst-case pause; nó không sửa retention.

Ở database, thu normalized query latency, row count, pool wait và execution plan. Tìm N+1, index kém, statistic cũ, lock wait và dữ liệu thừa. Kiểm tra với cardinality gần production; plan tốt trên 1.000 row đều có thể tệ trên 100 triệu row lệch.

Bản gom nhóm giảm CPU xuống O(event_count + user_count) nhưng lưu một aggregate mỗi user. Hãy đo peak heap. Nếu cardinality vô hạn, aggregate trong database, stream input đã sắp xếp, phân vùng map hoặc giới hạn báo cáo để không chuyển nút thắt sang bộ nhớ.

Triển khai an toàn, ngăn regression và tránh bẫy tối ưu

Profiling production cần ngân sách overhead, thời lượng, phạm vi, quyền truy cập và rollback. Bắt đầu từ metrics/trace, chỉ sampling chi tiết trên canary hoặc traffic nhỏ và giữ capture ngắn. Profile có thể chứa URL, SQL, argument và dữ liệu khách hàng. Heap snapshot còn gây stop-the-world và tốn bộ nhớ.

Triển khai qua flag hoặc canary, so traffic tương đương theo route và input. Theo dõi percentile, throughput, lỗi, CPU/request, bộ nhớ, GC, dependency và tính đúng. Service nhanh hơn nhưng tăng gấp đôi tải database chỉ chuyển chi phí. Rollback phải sẵn sàng.

Sau xác nhận, thêm bảo vệ đúng cấp. Timing threshold dễ flaky trên CI; dùng budget rộng, nhiều process, dữ liệu xu hướng hoặc assertion theo operation count/cardinality. Thêm load test cho service objective và alert theo triệu chứng người dùng.

Các bẫy thường lặp lại gồm:

  • Tối ưu mã trông có vẻ xấu mà chưa profile đường chạy đại diện.
  • So debug với release, khác phiên bản Node hoặc khác input.
  • Chỉ báo cáo lượt nhanh nhất hay latency trung bình.
  • Tuning p50 trong khi p99, lỗi hoặc throughput xấu đi.
  • Thêm cache nhưng thiếu invalidation, giới hạn cardinality và hit rate.
  • Đổi mã dễ đọc lấy cải thiện nhỏ hơn variance.
  • Xem async là CPU song song dù JavaScript vẫn chặn event loop.
  • Dùng worker nhưng bỏ qua serialization, transfer và queueing.
  • Tăng timeout, pool hoặc heap để che saturation.

Tip

Giữ nhật ký điều tra gồm command chính xác, commit, môi trường, workload, vị trí kết quả thô, profile, giả thuyết và quyết định. Giả thuyết thất bại vẫn có giá trị vì ngăn một phỏng đoán hấp dẫn tiêu tốn thêm một sự cố khác.

Những điều cần nhớ

Tối ưu thực sự bắt đầu từ phân phối phía người dùng và kết thúc bằng bằng chứng production. Đo percentile, throughput, lỗi và tài nguyên cùng nhau. Tái hiện đúng dữ liệu và concurrency; dùng sampling tìm hot stack, instrumentation giải thích phase đã biết.

Đọc profile theo tài nguyên: chiều rộng CPU không phải I/O wait, heap lớn không tự động là leak, GC pause cần bằng chứng allocation. Load test cả đường cong, database, hàng đợi và chi phí mới do candidate tạo ra.

Quan trọng nhất, tối ưu cơ chế có thể bị bác bỏ. Ví dụ thắng nhờ loại bỏ lượt quét lặp, không phải viết lại Array.filter. Canary thay đổi, giữ guardrail và biến kết quả thành kiểm tra regression. Đó là cách đưa hiệu năng vào vòng lặp kỹ thuật.