Kiểm thử tải gRPC trên HTTP/2: từ RPC latency đến giới hạn concurrent streams

“Dịch vụ chịu được 20.000 RPC/s” chưa phải tiêu chí kiểm thử. Cần chỉ rõ method, kiểu RPC, request/response size, deadline, tỷ lệ lỗi cho phép, số client, cách tái sử dụng channel, TLS, cơ chế cân bằng tải và khoảng thời gian steady state. Cùng một RPS nhưng unary payload 1 KiB khác hoàn toàn bidirectional stream kéo dài với message 64 KiB.

Mỗi test case nên gắn với quyết định: xác định capacity, so sánh phiên bản, sizing backend, kiểm tra autoscaling hay nghiệm thu SLO. Nếu mục tiêu là capacity, tải phải tăng từng bậc tới điểm bão hòa. Nếu mục tiêu là SLO, giữ tải đại diện và quan sát p95/p99 trong thời gian đủ dài.

Topology tối thiểu gồm load generator, DNS/service discovery, load balancer hoặc proxy nếu có, cụm gRPC backend và hệ thống telemetry. Với Kubernetes, ghi rõ đường đi qua ingress/gateway, service, sidecar/service mesh và CNI. Chạy thêm đường trực tiếp tới backend để tạo baseline, nhưng không dùng baseline đó thay cho kết quả end-to-end.

Thu timestamp tại client cho toàn bộ RPC; metric tại proxy và server để phân rã. Đồng bộ clock nếu ghép log nhiều hệ thống. Ghi phiên bản client library, server library, proxy, TLS, cipher suite, CPU limit, memory limit, số pod, connection pool và HTTP/2 setting thực tế.

Tách method theo tỷ trọng thay vì dùng một endpoint “echo” cho mọi kết luận. Mỗi method cần phân phối payload, think time, deadline và metadata gần thực tế. Với streaming, xác định thời lượng stream, message rate, hướng truyền và hành vi half-close. Với unary, đo cả cold channel và warm channel vì handshake DNS/TCP/TLS có thể làm sai tail latency.

Không đổi payload, concurrency và số backend trong cùng một bước nếu mục tiêu là tìm nguyên nhân. Dùng seed cố định cho dữ liệu ngẫu nhiên và lưu file cấu hình tải cùng kết quả.

• Biến: Kiểu RPC · Mức kiểm thử gợi ý: unary; server/client/bidi streaming · Bằng chứng: kết quả riêng từng kiểu
• Biến: Payload · Mức kiểm thử gợi ý: 1 KiB; 16 KiB; 256 KiB; phân phối thực · Bằng chứng: bytes/RPC, throughput
• Biến: Concurrency · Mức kiểm thử gợi ý: 10; 100; 500; tăng tới saturation · Bằng chứng: active RPC, queue depth
• Biến: Channel · Mức kiểm thử gợi ý: 1; pool 4/8; theo worker · Bằng chứng: connection và stream count
• Biến: TLS · Mức kiểm thử gợi ý: tắt trong baseline; bật theo production · Bằng chứng: handshake, CPU, cipher
• Biến: Deadline · Mức kiểm thử gợi ý: ngắn/trung bình/dài theo SLO · Bằng chứng: DEADLINE_EXCEEDED
• Biến: Backend · Mức kiểm thử gợi ý: 1; N; scale-out/scale-in · Bằng chứng: phân phối tải từng instance

gRPC thường ánh xạ nhiều RPC lên HTTP/2 connection. Khi số stream hoạt động đạt giới hạn của connection, RPC mới có thể bị xếp hàng phía client. Vì vậy CPU server còn rảnh không chứng minh hệ thống chưa bão hòa. Cần quan sát active streams, số connection, client-side pending/queue time và mức phân phối qua backend.

Tài liệu gRPC khuyến nghị tái sử dụng stub/channel khi có thể, nhưng cũng lưu ý workload tải cao hoặc long-lived stream có thể gặp queueing do giới hạn concurrent streams. Pool nhiều channel có thể là biện pháp kiểm chứng, không nên mặc định coi đó là cấu hình tối ưu. Thử 1, 2, 4 và 8 channel trong cùng traffic profile để tìm điểm thay đổi, đồng thời xác nhận load balancer không ghim toàn bộ long-lived stream vào ít backend.

Flow control HTTP/2 tác động theo connection và stream. Nếu receiver xử lý chậm, cửa sổ cạn có thể tạo backpressure. Thu flow-control stall, send/receive queue và application processing time để tránh gán mọi tail latency cho mạng.

KPI chính gồm successful RPC/s, message/s với streaming, throughput hai chiều, latency p50/p95/p99/max, status code, deadline exceeded, retry và tỷ lệ RPC hoàn tất. Báo theo method, không chỉ tổng hệ thống. Với streaming, thêm time-to-first-message, inter-message gap, stream duration và stream reset.

Tại transport, thu HTTP/2 connection count, active/pending streams, SETTINGS, reset, flow-control stall, TCP retransmission và TLS handshake. Tại backend, thu request queue, handler time, CPU throttling, memory, garbage collection, thread/event-loop utilization và load distribution.

Một kết luận capacity chỉ hợp lệ khi có offered load và achieved load. Nếu generator đạt 50.000 offered RPC/s nhưng chỉ phát thành công 35.000 vì client queue, capacity quan sát được là 35.000 với latency/error tương ứng, không phải 50.000.

Bắt đầu smoke test ở 5–10% tải mục tiêu, tiếp theo baseline một backend, scale-out, steady-state, spike, soak và failure. Mỗi bậc tải nên giữ đủ lâu để queue và autoscaling ổn định. Spike đo khả năng hấp thụ đột biến; soak phát hiện leak, connection churn và GC pause.

Ví dụ pass/fail: ở 15.000 RPC/s trong 30 phút, success ≥ 99,95%, p95 ≤ 80 ms, p99 ≤ 150 ms, không có RESOURCE_EXHAUSTED ngoài ngân sách lỗi, phân phối backend không lệch quá ngưỡng đã định và CPU throttling không kéo dài. Ngưỡng phải xuất phát từ SLO và workload của hệ thống, không sao chép con số này.

Negative test cần gồm backend chậm, một instance mất, DNS/service discovery thay đổi, load balancer restart, packet loss nhẹ, deadline ngắn và client retry. Retry có thể làm offered load tăng đúng lúc hệ thống yếu nhất; luôn đo cả original RPC và retry attempt.

• Ghi commit/build, version và cấu hình toàn bộ thành phần.
• Xác nhận clock, DNS, certificate và health trước khi chạy.
• Warm-up channel, connection và cache theo quy tắc cố định.
• Chạy smoke test; xác nhận generator không phải bottleneck.
• Tăng tải từng bậc, mỗi bậc chỉ thay một biến.
• Giữ steady state; lưu dữ liệu thô theo cùng test ID.
• Chạy failure và recovery khi traffic vẫn đang phát.
• Lặp ít nhất ba vòng; báo median, p95 và worst run.
• Kết thúc bằng cooldown và xác nhận queue trở về baseline.

Nếu p99 tăng nhưng handler time ổn định, kiểm tra client queue, concurrent streams, proxy queue và retransmission. Nếu thêm channel làm latency giảm mạnh trong khi backend không đổi, giới hạn connection/stream hoặc cách phân phối có thể là nút thắt; cần xác nhận bằng transport metric, không kết luận từ tương quan duy nhất.

Nếu RPS tăng tuyến tính nhưng error tăng sau một ngưỡng, phân loại status: DEADLINE_EXCEEDED chỉ ra deadline bị vượt, RESOURCE_EXHAUSTED có thể đến từ quota hoặc saturation, UNAVAILABLE thường gắn với đường truyền hoặc backend availability. Đừng gộp mọi lỗi thành “failed request”.

Nếu một số backend nóng hơn, kiểm tra connection stickiness, long-lived stream và thuật toán load balancing. Scale-out không bảo đảm cân bằng lại stream đã tồn tại.

Kết quả chỉ áp dụng cho method mix, payload, client/server runtime, HTTP/2 setting, TLS, proxy, topology và tài nguyên đã thử. Echo benchmark không đại diện cho business logic có database hoặc downstream service. Một generator trong cùng data center không đại diện cho client đa vùng.

Benchmark cũng không tự chứng minh correctness, authorization hoặc resilience ngoài ma trận. Capacity nên được công bố kèm SLO, error budget và evidence; thay đổi runtime, proxy hay service mesh cần regression test.