1. What is Performance Testing?
Performance Testing is the process of evaluating the speed, scalability and stability of a system under different load conditions. The goal is not just "does the system work?" but "how well does the system work?".
2. Types of Performance Test
| Test Type | Purpose_ | Example_ |
|---|---|---|
| Load Test | Evaluate the system under expected load | 500 concurrent users in 30 minutes__HTMLTAG_97___ |
| Stress Test | _Find breaking point | Increasing from 100→5000 users |
| Spike Test | Evaluate response to sudden load | 0→3000 users in 10 seconds |
| Soak/Endurance Test | Detect memory leaks, resource exhaustion_ | 200 users continuously for 24 hour |
| Scalability Test | Assess auto-scaling capabilities | Increase load, observe HPA scale-out |
| Volume Test | Test with large amount of data | 10 million records in database |
| Breakpoint Test | Determine maximum capacity | Increase gradually until error rate > 1% |
3. Key Metrics — Key Metrics
3.1 Latency
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
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. Performance Testing Process
┌──────────────────────────────────────────────────────────┐
│ 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. Summary
- Performance Testing is more than just "running tests" — requires a systematic process from Plan → Report
- Use percentiles (p95, p99) instead of average to evaluate latency
- Four Golden Signals: Latency, Traffic, Errors, Saturation
- Performance budgets helps set clear expectations
- Workload modeling must reflect actual user behavior
The next article will learn SRE Practices — SLO, SLI, SLA and Error Budgets.