1. Performance Testing là gì?
Performance Testing (kiểm thử hiệu năng) là quá trình đánh giá tốc độ, khả năng mở rộng và độ ổn định của hệ thống dưới các điều kiện tải khác nhau. Mục tiêu không chỉ là "hệ thống có chạy được không?" mà là "hệ thống hoạt động tốt đến đâu?".
2. Các loại Performance Test
| Loại test | Mục đích | Ví dụ |
|---|---|---|
| Load Test | Đánh giá hệ thống dưới tải dự kiến | 500 users đồng thời trong 30 phút |
| Stress Test | Tìm điểm giới hạn (breaking point) | Tăng dần từ 100→5000 users |
| Spike Test | Đánh giá phản ứng với tải đột ngột | 0→3000 users trong 10 giây |
| Soak/Endurance Test | Phát hiện memory leaks, resource exhaustion | 200 users liên tục trong 24 giờ |
| Scalability Test | Đánh giá khả năng auto-scale | Tăng tải, quan sát HPA scale-out |
| Volume Test | Kiểm tra với lượng data lớn | 10 triệu records trong database |
| Breakpoint Test | Xác định dung lượng tối đa | Tăng dần đến khi error rate > 1% |
3. Key Metrics — Các chỉ số quan trọng
3.1 Latency (Độ trễ)
Phân phối latency (percentiles):
┌─────────┬──────────┬────────────────────────────────────┐
│ Metric │ Giá trị │ Ý nghĩa │
├─────────┼──────────┼────────────────────────────────────┤
│ p50 │ 120ms │ 50% requests < 120ms (median) │
│ p90 │ 350ms │ 90% requests < 350ms │
│ p95 │ 580ms │ 95% requests < 580ms │
│ p99 │ 1200ms │ 99% requests < 1.2s │
│ p99.9 │ 3500ms │ 1 trong 1000 requests > 3.5s │
└─────────┴──────────┴────────────────────────────────────┘
⚠️ KHÔNG dùng average (mean) để đánh giá!
Dùng percentiles (p95, p99) để thấy được tail latency
3.2 Throughput
Throughput = Requests per Second (RPS) hoặc Transactions per Second (TPS)
Ví dụ: API /api/products → 2,500 RPS
API /api/checkout → 150 TPS (transaction nặng hơn)
Saturated throughput = RPS tối đa mà không tăng latency đáng kể
3.3 Error Rate
Error Rate = (Số request lỗi / Tổng requests) × 100%
SLO targets thường gặp:
- API services: Error rate < 0.1% (99.9% success)
- Web pages: Error rate < 0.5%
- Background jobs: Error rate < 1%
3.4 Saturation (Mức bão hòa)
Resource utilization cần monitor:
- CPU: < 70% sustained (headroom cho spike)
- Memory: < 80% (tránh OOM kills)
- Disk I/O: IOPS vs provisioned capacity
- Network: Bandwidth utilization
- Connection pools: Active / Max connections
- Thread pools: Active / Max threads
4. Four Golden Signals (Google SRE)
┌─────────────────────────────────────────────────────┐
│ FOUR GOLDEN SIGNALS │
├─────────────┬───────────────────────────────────────┤
│ Latency │ Thời gian xử lý request │
│ Traffic │ Lượng request/demand vào hệ thống │
│ Errors │ Tỷ lệ request thất bại │
│ Saturation │ Mức độ "đầy" của resources │
└─────────────┴───────────────────────────────────────┘
→ Monitor 4 signals này = bao phủ 80% vấn đề performance
5. Performance Budgets
# performance-budget.yml — Ví dụ cho E-commerce
pages:
home:
first_contentful_paint: 1.5s
largest_contentful_paint: 2.5s
time_to_interactive: 3.5s
total_bundle_size: 300KB (gzipped)
product_detail:
api_response_time_p95: 200ms
page_load: 2.0s
checkout:
api_response_time_p99: 500ms
transaction_completion: 3.0s
apis:
/api/products:
p95_latency: 150ms
throughput: 3000 RPS
error_rate: 0.05%
/api/orders:
p95_latency: 300ms
throughput: 500 TPS
error_rate: 0.01%
6. Quy trình Performance Testing
┌──────────────────────────────────────────────────────────┐
│ QUY TRÌNH PERFORMANCE TESTING │
├──────────────────────────────────────────────────────────┤
│ │
│ 1. PLAN │
│ ├── Xác định scope và objectives │
│ ├── Phân tích NFRs (SLO/SLA targets) │
│ ├── Thiết kế workload model │
│ └── Chuẩn bị test environment │
│ │
│ 2. DESIGN │
│ ├── Thiết kế test scenarios │
│ ├── Xác định test data │
│ ├── Viết test scripts │
│ └── Thiết lập monitoring/observability │
│ │
│ 3. EXECUTE │
│ ├── Baseline test (low load) │
│ ├── Load test (expected load) │
│ ├── Stress test (beyond capacity) │
│ └── Soak test (sustained load) │
│ │
│ 4. ANALYZE │
│ ├── Thu thập metrics │
│ ├── Xác định bottlenecks │
│ ├── Root cause analysis │
│ └── So sánh với SLO targets │
│ │
│ 5. REPORT │
│ ├── Executive summary │
│ ├── Technical findings │
│ ├── Recommendations │
│ └── Capacity planning │
│ │
│ 6. ITERATE │
│ ├── Fix bottlenecks │
│ ├── Re-test │
│ └── Continuous performance monitoring │
│ │
└──────────────────────────────────────────────────────────┘
7. Workload Modeling
Ví dụ workload model cho E-commerce (peak hour):
User Journey Distribution:
├── Browse products: 60% users
│ GET /api/products (list)
│ GET /api/products/:id (detail)
│ GET /api/reviews/:productId
│
├── Search: 25% users
│ GET /api/search?q=...
│
├── Add to cart: 10% users
│ POST /api/cart/items
│ GET /api/cart
│
└── Checkout: 5% users
POST /api/orders
POST /api/payments
GET /api/orders/:id
Think time: 3-8 seconds giữa các actions
Ramp-up: 0 → 1000 VUs trong 5 phút
Steady state: 1000 VUs trong 30 phút
8. Tổng kết
- Performance Testing không chỉ là "chạy test" — cần quy trình bài bản từ Plan → Report
- Dùng percentiles (p95, p99) thay vì average để đánh giá latency
- Four Golden Signals: Latency, Traffic, Errors, Saturation
- Performance budgets giúp set expectations rõ ràng
- Workload modeling phải phản ánh actual user behavior
Bài tiếp theo sẽ tìm hiểu SRE Practices — SLO, SLI, SLA và Error Budgets.