Đọc con số tải cơ bản: RPS, latency, p95, error rate
Từ hàng đợi đến dashboard
Bài trước bạn đã học cách đẩy tác vụ nặng ra background để request của người dùng không phải chờ. Nhưng đẩy việc đi rồi thì vẫn phải biết hệ thống đang khỏe hay sắp sập. Đó là lúc dashboard lên tiếng. Tôi từng trực một đợt sale: RPS gấp 6 lần ngày thường, dashboard vẫn xanh, 20 phút sau app sập. Con số không thiếu, chúng tôi chỉ đọc sai.
Sau bài này bạn sẽ:
- Đọc được 4 con số nền: RPS, latency, p95, error rate.
- Phân biệt trung bình cộng và phân vị, biết vì sao p95 đáng tin hơn.
- Ghép 4 con số thành một câu chẩn đoán: nghẽn ở đâu.
- Ước lượng số request đồng thời bằng RPS × latency.
Bốn con số, bốn câu hỏi khác nhau
Mỗi con số trả lời đúng một câu hỏi. Đọc sai câu hỏi là chẩn đoán sai bệnh.
| Con số | Trả lời câu hỏi | Đơn vị | Báo động khi |
|---|---|---|---|
| RPS | Hệ thống đang nhận bao nhiêu việc? | request/giây | Vượt baseline đã đo |
| Latency | Một request mất bao lâu? | ms | p95 vượt ngưỡng chấp nhận |
| p95 | Nhóm người dùng chậm nhất đang chờ bao lâu? | ms | Tăng nhanh hơn RPS |
| Error rate | Bao nhiêu phần trăm request thất bại? | % | Vượt 1% kéo dài |
RPS: đo lưu lượng, không đo sức khỏe
RPS là số request server nhận trong một giây. Nó cho biết áp lực đầu vào, không cho biết hệ thống chịu được hay không.
Cái bẫy nằm ở chỗ dashboard thường vẽ RPS theo phút. Ví dụ: 3.000 request trong 60 giây, ai nhìn cũng thấy 50 RPS, rất nhẹ nhàng. Nhưng nếu 400 RPS dồn vào 5 giây đầu (một chiến dịch flash sale), thì đỉnh thật là 400 RPS, gấp 8 lần con số trung bình. Cửa sổ đo quá rộng sẽ giấu mất đỉnh.
Note: Khi điều tra, luôn kéo cửa sổ xuống 1 giây hoặc 10 giây. Đỉnh 5 giây là thứ làm cạn connection pool, không phải con số trung bình phút.
Latency và p95: vì sao trung bình cộng nói dối
Latency là thời gian xử lý một request, đo bằng ms. Vấn đề: một con số trung bình gộp mọi người dùng lại và giấu đi nhóm chậm nhất.
Lấy 20 request, sắp xếp tăng dần (ms):
In this lesson
- Error rate: đèn báo sập sớm
- Ghép bốn con số: đọc một đợt tăng tải thật
- Mang bốn con số này vào ca trực đầu tiên
About this course
Part of App chịu tải: load balancer, stateless và rate limiting — Hiểu vì sao app sập khi đông người dùng và biết các bước cơ bản để sản phẩm chịu tải tốt hơn mà không cần tối ưu quá sớm.
- Level
- Beginner
- Goal
- Fundamentals
- Language
- Vietnamese
- Focus
- scale ngang và stateless load balancer connection pool rate limiting và queue
- Prior knowledge
- Biết viết API đơn giản, Hiểu khái niệm server và database
- Practice
- Worked examples
- Time
- ~3h
- Voice
- một SRE kể lại các đợt traffic tăng vọt, dạy bằng con số và sơ đồ, luôn chỉ ra 'nút thắt tiếp theo' thay vì tối ưu mọi thứ cùng lúc
- Not covered
- autoscaling nâng cao, thiết kế hệ phân tán chuyên sâu, tuning kernel
This lesson is premium content. Sign in and purchase the course to view the full content. Sign in