Trước khuyến mãi hoặc quảng cáo lớn, hãy kiểm tra website có phục vụ được nhiều khách không. Doanh nghiệp cần dự kiến số người truy cập và các việc quan trọng như mua hàng, gửi liên hệ. Đội kỹ thuật sẽ lập kế hoạch năng lực (Capacity Planning) và kiểm thử tải (Load Testing) một cách an toàn.
Chủ doanh nghiệp cần làm gì? Cung cấp thông tin về chiến dịch, lượng khách dự kiến và chức năng không được phép lỗi. Đội kỹ thuật thử tải và tìm nguyên nhân gây chậm trước khi đề xuất nâng hosting. Không nên mặc định cứ đông khách là phải đổi máy chủ.
Khi nào cần kiểm tra website có chịu được nhiều khách?
| Trường hợp | Rủi ro | Thông tin cần chuẩn bị |
|---|---|---|
| Sắp livestream, khuyến mãi hoặc quảng cáo | Nhiều khách cùng truy cập | Giờ sự kiện, kênh quảng cáo, trang đích và lượng khách dự kiến |
| Website bán hàng tăng đơn | Giỏ hàng, thanh toán quá tải | Các bước mua hàng cần bảo vệ |
| Chuyển hosting, cập nhật lớn | Hiệu năng thay đổi sau nâng cấp | Số liệu tốc độ và giao dịch trước thay đổi |
| Website chậm thường xuyên giờ cao điểm | Có thể có điểm nghẽn | Thời gian xảy ra và chức năng bị ảnh hưởng |
Với website nhỏ, chưa có giao dịch hoặc sự kiện lớn, có thể bắt đầu từ giám sát. Không nên tổ chức kiểm thử tốn kém nếu chưa có mục tiêu rõ.
Trước chiến dịch, chủ doanh nghiệp cần chuẩn bị gì?
- Phạm vi: ưu tiên xem sản phẩm, tìm kiếm, gửi liên hệ hay thanh toán.
- Lượng khách: sử dụng số liệu giờ cao điểm và đơn hàng từ chiến dịch trước, nếu có.
- Chi phí: môi trường thử, công cụ, nhân sự, tài nguyên tăng thêm và đo sau khi sửa.
- Quyền và nghiệm thu: ai cho phép kiểm thử, ai trực xử lý, kết quả thế nào mới được triển khai.
Ví dụ giả định: cửa hàng chuẩn bị giảm giá hai ngày. Kỹ thuật cần thử xem trang sản phẩm, giỏ hàng và thanh toán hoạt động thế nào khi khách tăng. Không thể dùng số người theo dõi mạng xã hội thay cho số khách truy cập đồng thời.
Lập kế hoạch chịu tải khác với kiểm thử như thế nào?
| Hoạt động | Kết quả cần có |
|---|---|
| Lập kế hoạch (Capacity Planning) | Lượng tải dự kiến và năng lực dự phòng (headroom) |
| Kiểm thử tải (Load Testing) | Số đo độ trễ, lỗi, số thao tác hoàn tất |
| Đánh giá mở rộng | Biết điều chỉnh nào giúp tăng khả năng xử lý, chi phí đi kèm |
Lập kế hoạch là ước tính website cần phục vụ bao nhiêu khách. Kiểm thử là chạy thử các thao tác để xem hệ thống xử lý được đến đâu. Nên kiểm tra lại sau thay đổi lớn.
Bước 1. Xem website hoạt động ra sao trong ngày thường
Baseline là mốc số liệu khi website hoạt động ổn định. Kỹ thuật cần đo số người dùng đồng thời (concurrency), số yêu cầu hoặc giao dịch xử lý mỗi giây (throughput), tỷ lệ lỗi và mức sử dụng tài nguyên.
Thời gian phản hồi có thể xem theo p50/p75/p95: lần lượt 50%, 75%, 95% yêu cầu hoàn tất trong mức thời gian đó. p95 giúp nhận ra nhóm yêu cầu chậm hơn trung bình.
Ghi CPU, RAM, I/O, PHP worker và kết nối dữ liệu. Xem giám sát website để có số liệu theo thời gian.
Bước 2. Thử đúng những việc khách thường làm
Không chỉ thử trang chủ. Khách còn tìm sản phẩm, gửi liên hệ, thêm vào giỏ và thanh toán. Những thao tác này có thể chậm dù trang chủ vẫn mở nhanh.
| Thao tác | Nơi có thể nghẽn | Cần xác nhận |
|---|---|---|
| Xem sản phẩm, nội dung | Ảnh, cache, máy chủ | Trang đúng và đủ dữ liệu |
| Tìm kiếm, lọc | Cơ sở dữ liệu, CPU | Kết quả trả về đúng |
| Gửi biểu mẫu | Email, CRM hoặc API | Yêu cầu được tiếp nhận |
| Thanh toán | Giỏ hàng, dữ liệu, cổng thanh toán | Không mất hoặc trùng đơn |
| Đăng nhập | Phiên, PHP worker | Đúng tài khoản và bảo vệ dữ liệu |
Bước 3. Chọn cách thử khi lượng khách tăng
| Loại thử | Câu hỏi cần trả lời |
|---|---|
| Load test – tải dự kiến | Website có xử lý tốt mức khách mong đợi không? |
| Stress test – tải vượt dự kiến | Bắt đầu chậm hoặc lỗi khi vượt mức nào? |
| Spike test – tải tăng đột ngột | Hệ thống, hàng đợi và tự mở rộng phản ứng ra sao? |
| Soak test – tải kéo dài | Có rò rỉ bộ nhớ hoặc tích tụ công việc không? |
Kịch bản có thể tăng mức tải từ từ, giữ trong một khoảng rồi giảm. Grafana k6 hướng dẫn xây mức tải theo hành vi. Số người dùng ảo và thời gian thử phải được lựa chọn theo từng website, không lấy từ ví dụ mẫu.
Bước 4. Tránh làm gián đoạn website đang bán hàng
Không tự ý tăng tải trên website đang phục vụ khách. Ưu tiên môi trường kiểm thử gần giống hệ thống thật. Dùng dữ liệu giả lập hoặc dữ liệu đã loại thông tin cá nhân. Kiểm tra quy định hosting và lấy quyền phê duyệt trước khi bắt đầu.
- Đặt người phụ trách, khung giờ, phạm vi và mức tải tăng dần.
- Không chạy thanh toán thật hoặc tạo hàng loạt đơn thử ngoài kiểm soát.
- Đặt điều kiện dừng khi p95, tỷ lệ lỗi hoặc chức năng quan trọng vượt mức đã thống nhất.
- Chuẩn bị cơ chế giới hạn yêu cầu (rate-limit), xử lý hàng đợi (queue) và phương án hoàn tác (rollback).
- Dừng kiểm thử và xác minh hệ thống trở lại bình thường khi có dấu hiệu rủi ro.
AWS Well-Architected khuyến nghị thử luồng quan trọng trong môi trường giống thật, với dữ liệu thử an toàn. Microsoft nhấn mạnh mục tiêu và ngưỡng đạt/không đạt phải đo được.
Dành cho kỹ thuật — Bước 5. Đọc kết quả và tìm chỗ quá tải
Đừng chỉ xem số người dùng tối đa. Kỹ thuật cần đối chiếu tốc độ p50/p75/p95, throughput, tỷ lệ lỗi và tỷ lệ hoàn tất thao tác.
Đồng thời xem CPU, RAM, I/O, PHP worker, kết nối cơ sở dữ liệu, độ trễ API và số công việc chờ trong queue.
Nếu máy chủ quá tải, xem dấu hiệu cạn tài nguyên. Nếu truy vấn chậm, xem hiệu năng cơ sở dữ liệu. Một lần CPU cao chưa đủ kết luận hosting thiếu năng lực.
Cache HIT nghĩa là có bản dữ liệu lưu sẵn; cache MISS nghĩa là phải lấy hoặc tạo lại. Kỹ thuật nên đánh giá trường hợp cache đã có dữ liệu (warm cache) và chưa có (cold cache) nếu phù hợp thực tế. Xem Cache và CDN.
Năng lực dự phòng (headroom) là khoảng còn lại trước khi website không đáp ứng được mục tiêu. Không có tỷ lệ headroom cố định: hãy xét thời gian mở rộng, chi phí và độ quan trọng của chức năng.
Kiểm tra chịu tải có thể tốn những khoản nào?
Chi phí có thể gồm môi trường thử, nhân sự, công cụ, số lần thử lại và năng lực dự phòng. Google Cloud cũng yêu cầu đánh giá hạn mức tài nguyên và phí phát sinh trước sự kiện. Không thể báo giá cố định khi chưa biết kịch bản và hạ tầng.
Làm sao biết website đã sẵn sàng trước khuyến mãi?
| Nội dung cần duyệt | Bằng chứng cần có |
|---|---|
| Đã thử đúng luồng quan trọng? | Kịch bản và kết quả từng bước |
| Website đạt tốc độ mục tiêu? | p95, tỷ lệ lỗi và throughput ở mức tải dự kiến |
| Biểu mẫu, thanh toán không bị lỗi? | Tỷ lệ hoàn tất và kết quả thử an toàn |
| Có đủ dự phòng nếu lượng khách cao hơn? | Headroom, cảnh báo, cách giảm tải hoặc mở rộng |
| Chi phí và quyền đã rõ? | Dự toán và người ký xác nhận |
SLO là mục tiêu mức dịch vụ; SLA là cam kết mức dịch vụ theo thỏa thuận nếu có. Ngưỡng p95 và tỷ lệ lỗi cần thống nhất từ nhu cầu kinh doanh trước kiểm thử. Không sao chép con số minh họa của công cụ thành chuẩn chung.
Câu hỏi thường gặp
Website đông khách có nhất thiết phải nâng hosting?
Không. Cần xác định điểm nghẽn nằm ở phần mềm, cơ sở dữ liệu, bộ nhớ đệm hay tài nguyên rồi mới quyết định.
Website nhỏ có cần thử tải không?
Không phải lúc nào cũng cần. Nếu không sắp có thay đổi lớn, giám sát thường là bước bắt đầu phù hợp.
Có thể kiểm thử trực tiếp trên website thật không?
Chỉ khi có quyền, mục đích rõ và biện pháp an toàn cho khách. Nên ưu tiên môi trường kiểm thử tách biệt.
Website đang chậm thì có tiếp tục thử tải không?
Không. Hãy dừng thử và xem cách xử lý website chậm bất thường để bảo vệ giao dịch.
Kết luận
Capacity Planning ước tính tải cần đáp ứng; Load Testing kiểm chứng bằng số liệu. Chủ doanh nghiệp chốt mục tiêu, chi phí và điều kiện nghiệm thu. Đội kỹ thuật cần bảo toàn các chỉ số chuyên môn, thử an toàn và tìm đúng điểm nghẽn. Đọc thêm quản lý hiệu năng và độ ổn định website.
Đ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ả.