Capacity Planning (lập kế hoạch năng lực) & Load Testing (kiểm thử tải) cho website giúp doanh nghiệp biết workload hiện tại, phần năng lực dự phòng (headroom) còn lại và cách hệ thống phản ứng khi traffic, số tác vụ đồng thời (concurrency) hoặc tác vụ nền tăng. Mục tiêu không phải tìm một con số “website chịu được bao nhiêu user” cho mọi tình huống, mà là xác định giới hạn theo luồng người dùng quan trọng (critical journey) và chuẩn bị mở rộng năng lực trước khi hiệu năng suy giảm.
Tóm tắt: Capacity Planning dùng baseline — mức bình thường để so sánh — cộng xu hướng tăng trưởng và sự kiện kinh doanh để ước lượng nhu cầu; Load Testing tạo tải có kiểm soát để quan sát độ trễ (latency), tỷ lệ lỗi, lượng công việc xử lý được (throughput), bão hòa tài nguyên và điểm nghẽn. Test phải phản ánh hành vi thật, không chỉ bắn request vào homepage.
Khi nào cần Capacity Planning và baseline gì trước khi test?
Nên làm capacity planning trước campaign/flash sale, migration hoặc nâng cấp hạ tầng; khi traffic tăng đều; khi saturation lặp lại ở giờ cao điểm; khi thêm integration hoặc workload nền lớn; hoặc khi mục tiêu độ tin cậy như SLO (Service Level Objective — mục tiêu mức dịch vụ) hay SLA (Service Level Agreement — cam kết mức dịch vụ) đòi hỏi headroom rõ.
Trước load test, khóa baseline production thực tế: requests/transactions theo thời gian, concurrency nếu có ý nghĩa, p50/p75/p95 latency, error rate, CPU/RAM/I/O/worker/DB connection, cache HIT/MISS và tỷ lệ thành công của critical journey. Không có baseline thì kết quả test khó gắn với thực tế production. Để theo dõi baseline liên tục, xem Website Monitoring.
Xây workload model theo critical journey, không chỉ homepage
Workload model là mô hình mô phỏng tỷ lệ và loại thao tác thực tế mà hệ thống phải xử lý. Homepage thường được cache tốt và không đại diện cho search, login, form, checkout hoặc API (Application Programming Interface — giao diện lập trình ứng dụng). Workload model nên phản ánh hành vi thật hoặc kịch bản kinh doanh cần bảo vệ.
| Journey | Ví dụ workload | Điểm cần quan sát |
|---|---|---|
| Browse | Homepage, category, article/product | Cache HIT, origin latency, asset delivery |
| Search/filter | Query động, filter, pagination | DB query, CPU, cache behavior |
| Lead | Landing → form → CRM | Form success, API/dependency latency |
| Commerce | Cart → checkout → payment callback | Business success rate, DB/API, timeout |
| Authenticated | Login → account/member area | Session, worker, personalized response |
Chọn loại test theo câu hỏi cần trả lời
| Loại test | Câu hỏi chính |
|---|---|
| Load test | Workload dự kiến có đáp ứng latency/error mục tiêu không? |
| Stress test | Hệ thống bắt đầu suy giảm hoặc chạm giới hạn ở đâu? |
| Spike test | Traffic tăng đột ngột làm queue, autoscaling hoặc dependency phản ứng thế nào? |
| Soak test | Chạy lâu có lộ memory leak, backlog tăng hoặc degradation theo thời gian không? |
Các chỉ số nên xem cùng nhau gồm latency theo percentile, error/timeout rate, throughput, CPU/RAM/I/O, PHP worker/queue, kết nối database/query time, cache HIT/MISS, độ trễ dependency và tỷ lệ thành công business flow.
Đọc bottleneck và headroom từ kết quả test
Không chỉ nhìn throughput tối đa. Hãy tìm điểm mà latency, queue hoặc error bắt đầu xấu cùng một resource hoặc dependency. Nếu test cho thấy CPU/worker/database/I/O tiến gần giới hạn, đi sâu tại Resource Saturation và Database Performance.
Cache cũng phải được đưa vào model. Chỉ test khi cache đã “ấm” (warm cache) có thể đánh giá thấp tải về máy chủ gốc; nếu purge, cache cold hoặc partial-cache là tình huống thực tế thì cần kịch bản tương ứng. Xem Cache & CDN.
Headroom là năng lực còn lại trước khi hệ thống bắt đầu suy giảm. Không có tỷ lệ headroom cố định cho mọi website; nó phụ thuộc mức biến động traffic, autoscaling, thời gian mở rộng, chi phí và mức quan trọng của dịch vụ. Khi test lộ bottleneck, đừng mặc định tăng server: xác định root cause rồi mới quyết định tối ưu, scale hoặc thay kiến trúc.
Load test an toàn: authorization, stop condition và rollback
Load test có thể tự gây incident. Ưu tiên staging hoặc môi trường hiệu năng đủ giống production. Nếu production test là cần thiết, phải có authorization, monitoring, owner, time window, traffic scope và stop condition — điều kiện phải dừng test rõ trước khi tạo tải.
Nếu latency/error vượt ngưỡng vận hành hoặc critical journey bắt đầu fail, dừng test và chuyển sang triage thay vì cố “tìm breaking point” bằng mọi giá. Flow xử lý website chậm bất thường nằm tại Website Performance Degradation.
Checklist trước campaign hoặc traffic event lớn
- Forecast traffic và critical journey.
- Baseline latency/error/throughput/resource.
- Workload model và loại test phù hợp.
- Warm/cold-cache scenario nếu có rủi ro thực tế.
- Database/resource/dependency monitoring.
- Alert, owner và stop condition.
- Scale/rollback/rate-limit/queue criteria.
- Post-test hoặc post-event review để cập nhật capacity model.
Kết luận
Capacity Planning & Load Testing giúp Website Performance & Reliability chuyển từ phản ứng sau sự cố sang chuẩn bị trước. Giá trị lớn nhất không nằm ở một con số “user tối đa”, mà ở việc biết critical journey nào chạm bottleneck trước, hệ thống còn bao nhiêu headroom và đội vận hành sẽ làm gì khi tải tăng.
Đoàn Trình Dục là Giảng viên Khoa Công nghệ Thông tin tại Đại học Công nghệ Sài Gòn (STU), với hơn 10 năm kinh nghiệm thực chiến trong các lĩnh vực Mạng máy tính, Marketing Online, SEO và Bảo mật hệ thống.
Với nền tảng sư phạm và kinh nghiệm tư vấn cho nhiều doanh nghiệp, thầy chuyên sâu vào việc xây dựng các giải pháp kỹ thuật số toàn diện và hiệu quả.
