Latency vs. Throughput vs. Bandwidth: Mô hình tư duy 'Ống nước'

“Làm cho API nhanh lên.”

Đây là cái task mơ hồ nhất mà một dev có thể nhận được. “Nhanh” nghĩa là nó phục vụ được nhiều người hơn (Throughput)? Hay là nó trả lời từng người lẹ hơn (Latency)?

Nhầm lẫn hai cái này là lý do tại sao bạn thêm 10 con server vào (tăng Throughput) mà câu query database vẫn mất 2 giây (Latency không đổi).

Đây là Hướng dẫn chuyên sâu về Hiệu năng hệ thống. Hãy vứt bỏ mấy định nghĩa sách giáo khoa và dùng hình ảnh chuẩn nhất: Ống nước.

Phần 1: Nền tảng (Mô hình tư duy)

Cái ống nước

Tưởng tượng kết nối dữ liệu là một đường ống dẫn nước từ A đến B.

Bandwidth = Độ rộng ống Cái ống to chừng nào?
- Đơn vị: Mbps (Megabits per second).
- Ý nghĩa: Giới hạn lý thuyết. Bạn không thể nhét con tàu Titanic qua cái vòi tưới cây được.
Latency = Tốc độ dòng chảy Mất bao lâu để một giọt nước đi từ A đến B?
- Đơn vị: Milliseconds (ms).
- Ý nghĩa: Tốc độ phản hồi. Kể cả ống to, nếu nó dài 100km thì latency vẫn cao (nhận nước chậm).
Throughput = Lưu lượng thực tế Có bao nhiêu nước thực sự đang chảy ra khỏi đầu ống ngay lúc này?
- Đơn vị: Requests per Second (RPS) hoặc TPS.
- Ý nghĩa: Thực tế. Thông lượng (Throughput) luôn luôn <= Băng thông (Bandwidth).

Chân lý:
Thêm Server làm tăng Throughput (Mở rộng đường cao tốc).
Tối ưu Code/DB làm giảm Latency (Tăng tốc độ xe chạy).

Nghịch lý “Tắc đường”

Bạn có thể có Throughput cực cao nhưng Latency cực tệ.

Ví dụ: Tắc đường trên cao tốc 10 làn xe.
Throughput: Cao (Hàng nghìn xe đi qua trạm thu phí mỗi giờ).
Latency: Cao (Mất 2 tiếng mới về đến nhà).

Phần 2: Điều tra (Chỉ số nào quan trọng?)

1. Cái bẫy của “Trung bình” (Average)

Đừng bao giờ nhìn số Trung bình (Mean). Nếu 9 request mất 100ms và 1 request mất 10,000ms (timeout):

Average: ~1,090ms.
Con số này nói dối. Nó bảo là “mọi người đều hơi chậm”, nhưng thực tế là 90% rất nhanh và 1 người đã chết.

2. Sử dụng Percentiles (P95, P99)

P50 (Median): Trải nghiệm “Bình dân”. 50% người dùng nhanh hơn mức này.
P95: Trải nghiệm “Xui xẻo”. 5% người dùng (1 trong 20) chậm hơn mức này.
P99: Trường hợp “Tệ nhất”. 1 trong 100 người đang chửi thề.

Quy tắc: Tối ưu theo P95. Nếu P95 ngon, thì hầu hết mọi người đều hài lòng.

3. Công cụ đo

Ping: Đo Network Latency (Đường ống rỗng).

1
2
ping google.com
# time=14.2 ms  <-- Thời gian di chuyển đơn thuần

Load Test (k6 / JMeter): Đo Throughput & Latency dưới áp lực cao.

Phần 3: Chẩn đoán (Tìm nút cổ chai)

Hệ thống chậm? Soi triệu chứng để bắt bệnh.

Triệu chứng	Chẩn đoán	Cách chữa
Latency cao, CPU thấp	I/O Bound. Đang ngồi chờ Database hoặc API bên ngoài.	Đánh Index DB, dùng Cache, gọi Async.
Latency cao, CPU cao	CPU Bound. Code đang tính toán quá nặng hoặc loop ngu.	Tối ưu thuật toán, Scale vertical (CPU xịn hơn).
Throughput đụng trần	Bão hòa (Saturation). Ống nước đầy rồi.	Scale Horizontal (Thêm server).
TTFB (Time To First Byte)	Backend chậm. Server suy nghĩ lâu quá.	Kiểm tra slow query log.

Phần 4: Giải pháp (Hành động)

1. Fix Latency (Làm cho nhanh hơn)

Latency thường là vấn đề về Chiều sâu. Bạn đang đào sâu quá.

Caching (Redis): Đừng tính toán nữa; nhớ kết quả thôi. (Giảm số lần đi gặp DB).
CDN (Cloudflare): Mang nội dung đến gần nhà người dùng hơn. (Giảm quãng đường đi).
Database Indexing: Tìm cái kim mà không cần bới cả đống rơm.

2. Fix Throughput (Làm cho to hơn)

Throughput là vấn đề về Chiều rộng. Cái ống quá hẹp.

Horizontal Scaling: Thêm server đằng sau Load Balancer.
Async Processing (Kafka/RabbitMQ): Đừng làm ngay; làm sau đi. Trả lời “OK” ngay lập tức, rồi xử lý ngầm (background).

Mô hình tư duy chốt hạ

1
2
3
4
5
6
Latency    -> Tốc độ xe chạy. (Sửa bằng cách mua Ferrari / Tối ưu động cơ).
Throughput -> Độ rộng mặt đường. (Sửa bằng cách thêm làn xe).
Bandwidth  -> Giới hạn vật lý. (Sửa bằng cách nâng cấp cáp quang).

"Web chậm quá" thường là Latency.
"Web sập rồi" thường là quá tải Throughput.

Lần tới sếp bảo “tăng hiệu năng”, hãy hỏi lại: “Sếp muốn mua Ferrari (Latency) hay muốn mở rộng đường quốc lộ (Throughput)?”