System Performance Objectives
🚀 System Performance Objectives
Hai mục tiêu quan trọng nhất của mọi hệ thống hiệu năng cao
Rất nhiều kỹ sư khi tối ưu performance thường chỉ nhìn vào CPU, RAM hoặc database.
Thực tế, trước khi tối ưu, bạn nên tự hỏi:
Mục tiêu cuối cùng của hệ thống là gì?
Chỉ có 2 mục tiêu cốt lõi.
System Performance
┌─────────────────────────────────┐
│ │
▼ ▼
Minimize Latency Maximize Throughput
(Response nhanh hơn) (Xử lý nhiều request hơn)
1) Objective #1 — Minimize Request-Response Latency
Latency là:
Khoảng thời gian từ lúc request được gửi cho đến khi client nhận được response.
Ví dụ:
Client
│
│ Request
▼
Server
│
│ Processing
▼
Response
│
▼
Client
Latency = Total Time
Đơn vị đo:
Milliseconds (ms)
Seconds (s)
Latency được tạo thành từ gì?
Một request không phải lúc nào cũng được xử lý ngay.
Nó thường trải qua hai giai đoạn:
Request Latency
┌──────────────┬──────────────┐
▼ ▼
Waiting Time Processing Time
Hay viết dưới dạng công thức:
Latency
=
Waiting Time
+
Processing Time
Waiting Time
Là khoảng thời gian request phải đứng chờ.
Ví dụ:
Request
↓
Queue
↓
CPU Available
↓
Execute
Nguyên nhân phổ biến:
- Thread Pool đầy
- Database đang bận
- Lock
- Network congestion
- Connection Pool hết
Processing Time
Là thời gian thực sự xử lý request.
Ví dụ:
Receive Request
↓
Business Logic
↓
Database Query
↓
Serialize JSON
↓
Response
Bao gồm:
- CPU
- Database Query
- Cache
- Network I/O
- Business Logic
Tổng quan Latency
Request
↓
Waiting
↓
CPU Execute
↓
Database
↓
Business Logic
↓
Response
Mục tiêu:
↓
Waiting Time
↓
Processing Time
↓
Latency
2) Objective #2 — Maximize Throughput
Nếu Latency trả lời câu hỏi:
Một request mất bao lâu?
Thì Throughput trả lời:
Trong một giây hệ thống xử lý được bao nhiêu request?
Ví dụ:
100 Requests
↓
1 Second
↓
100 RPS
Hoặc:
500 Transactions
↓
1 Minute
↓
500 TPM
Đơn vị thường dùng:
- Requests/Second (RPS)
- Transactions/Second (TPS)
- Queries/Second (QPS)
Throughput phụ thuộc vào điều gì?
Throughput không tự nhiên tăng.
Nó phụ thuộc vào hai yếu tố:
Throughput
│
┌────────────┴────────────┐
▼ ▼
Latency Capacity
Hay công thức tư duy:
Higher Throughput
=
Lower Latency
+
Enough Capacity
Nếu chỉ giảm Latency thì sao?
Ví dụ server xử lý:
100 ms / request
Một thread xử lý được:
10 request / second
Nếu tối ưu xuống:
50 ms / request
Thì throughput gần như tăng gấp đôi:
20 request / second
Đó là lý do:
Giảm Latency gần như luôn giúp tăng Throughput.
Nhưng Latency không phải tất cả
Nếu tài nguyên đã full:
CPU 100%
Memory 95%
Thread Pool 100%
Thì dù code tối ưu hơn nữa, throughput vẫn khó tăng nhiều.
Lúc này cần mở rộng capacity:
Capacity
↓
More CPU
More RAM
More Servers
Load Balancer
Request-Response Components
Không phải mọi thành phần trong hệ thống đều giống nhau.
Có hai loại:
Components
┌──────────────┴──────────────┐
▼ ▼
Request-Response Batch Processing
Request-Response System
Ví dụ:
Browser
↓
Web Server
↓
Business Service
↓
Database
↓
Response
Ở đây ta quan tâm:
- ✅ Latency
- ✅ Throughput
Batch Processing
Ví dụ:
Database
↓
Read Millions Rows
↓
Generate Report
↓
Export PDF
Không có request-response trực tiếp.
Chỉ có:
Batch Start
↓
Processing
↓
Finished
Điều quan trọng là:
- Total Processing Time
- Throughput
Chứ không phải per-request latency.
Kiến trúc tổng thể
Browser
│
HTTPS Request
│
▼
Web Application
│
▼
Business Service
│
▼
Database
│
Report / Analytics
▼
Batch Processing
Quan tâm từng tầng
| Component | Latency | Throughput |
|---|---|---|
| Web Application | ✅ | ✅ |
| Business Service | ✅ | ✅ |
| Database | ✅ | ✅ |
| Batch Job | ❌ | ✅ |
Từ góc nhìn Software Architect
Điều quan trọng nhất không phải là tăng CPU ngay.
Mà là biết đặt câu hỏi đúng thứ tự:
Performance Problem
│
▼
Is Latency High?
│
YES
│
▼
Reduce Waiting Time
Reduce Processing Time
Nếu latency đã thấp:
Need More Throughput?
↓
Increase Capacity
Nếu capacity cũng đủ:
System Scales
Mental Model
Performance
│
┌────────────────┴────────────────┐
▼ ▼
Latency Throughput
│ ▲
▼ │
Waiting + Processing │
│ │
└───────────────┬─────────────────┘
▼
Capacity
Kết luận
Có một quy tắc rất hữu ích khi phân tích hiệu năng:
Latency quyết định trải nghiệm của từng request, còn Throughput quyết định khả năng phục vụ của toàn hệ thống.
Với vai trò Software Engineer, Tech Lead hay Software Architect, thay vì bắt đầu bằng việc nâng cấu hình server, hãy luôn phân tích theo thứ tự:
- Latency có cao không? Nếu có, xác định nguyên nhân nằm ở Waiting Time hay Processing Time.
- Throughput đã đáp ứng tải chưa? Nếu chưa, đánh giá xem việc giảm latency còn hiệu quả hay hệ thống đã chạm giới hạn.
- Capacity đã đủ chưa? Chỉ mở rộng CPU, RAM hoặc số lượng server khi bottleneck thực sự đến từ tài nguyên.
Đây cũng chính là nền tảng để hiểu các chủ đề nâng cao hơn như Caching, Asynchronous Processing, Thread Pool, Connection Pool, Database Optimization, Load Balancing và Horizontal Scaling trong thiết kế hệ thống hiệu năng cao.