RPS là gì trong DevOps? Ý nghĩa và cách đọc chỉ số RPS

RPS (Requests Per Second) là chỉ số cho biết mỗi giây hệ thống nhận hoặc xử lý bao nhiêu request.
Trong các hệ thống web, một request thường là một HTTP request / API call từ client đến server.

Ví dụ:
Nếu trong 1 phút hệ thống xử lý 6.000 request, thì RPS trung bình là:

6.000 / 60 = 100 RPS

RPS phản ánh traffic mà hệ thống đang phải xử lý tại một thời điểm.

RPS cho biết điều gì?

RPS giúp trả lời nhanh các câu hỏi cơ bản:

Hệ thống đang nhận bao nhiêu traffic?
Traffic có spike theo peak hours hay không?
Sau khi deploy hoặc chạy campaign, request volume thay đổi thế nào?

Tuy nhiên, cần lưu ý: RPS chỉ phản ánh số lượng request, không đo performance/health của hệ thống.

RPS khác Latency và Error rate ra sao?

RPS thường được đọc cùng các chỉ số sau:

Latency: thời gian xử lý một request (ví dụ 120ms)
p95 latency: 95% request có latency thấp hơn mức này
Error rate: tỷ lệ request lỗi (đặc biệt là 5xx)

Một hệ thống có RPS cao chưa chắc “healthy” nếu latency tăng hoặc error rate cao.

Cách hiểu RPS

Một số nguyên tắc cơ bản khi đọc RPS:

RPS hiếm khi hiển thị realtime “thuần”, mà thường là average theo window 1–5 phút.
Nên xem RPS theo service hoặc endpoint, không chỉ nhìn tổng.
Luôn đọc RPS kèm latency và error rate để tránh kết luận sai.

Ví dụ:

RPS tăng nhưng latency ổn định → hệ thống đang handle load tốt.
RPS tăng và latency tăng → có risk saturation/overload (tùy bottleneck nằm ở đâu).
RPS giảm đột ngột → có thể xảy ra sự cố routing hoặc outage.

RPS thường được đo ở đâu?

Tuỳ mục tiêu observability, RPS có thể được đo tại:

Load balancer / Ingress / API Gateway: để biết traffic tổng vào hệ thống.
Từng service hoặc từng endpoint: để phát hiện nguồn gây bottleneck.

Trong vận hành thực tế, nên chọn 1–2 measurement point chính và giữ nhất quán.

Những yếu tố có thể làm RPS tăng ảo

Một số nguyên nhân khiến RPS cao hơn traffic thực:

Health check được tính chung vào request.
Retry khi hệ thống gặp lỗi (client-side hoặc server-side).
Redirect hoặc hành vi của CDN/LB tạo thêm request phụ.
Một số LB/CDN có thể tạo thêm request nội bộ.

Vì vậy, RPS nên được breakdown theo request type hoặc status code để đọc chính xác.

RPS được dùng để làm gì trong DevOps?

Ở mức cơ bản, RPS thường được dùng cho:

Theo dõi traffic theo thời gian.
Phát hiện anomaly khi xảy ra sự cố.
Hỗ trợ autoscaling (đặc biệt với workload I/O bound hoặc cache-heavy).
Làm dữ liệu đầu vào cho capacity planning và rate limiting.

Kết luận

RPS là chỉ số nền tảng để hiểu request volume mà hệ thống đang xử lý mỗi giây.
Tuy nhiên, RPS không phản ánh đầy đủ system health nếu đứng một mình.

Để đánh giá đúng, RPS cần được đọc cùng latency, error rate và các dấu hiệu saturation của tài nguyên. Đây là cách tiếp cận cơ bản nhưng hiệu quả trong vận hành các hệ thống web hiện đại.