Lập kế hoạch năng lực theo tải thực tế thay vì số người dùng danh nghĩa

Hai dịch vụ có cùng số tài khoản có thể chịu nhu cầu vận hành rất khác nhau. Một bên chỉ có tra cứu ngắn thỉnh thoảng, bên kia nhận tệp lớn và xử lý theo lịch. Quyết định năng lực cần mô tả công việc, không phải con số tiếp thị. Bắt đầu từ thao tác khách hàng cần hoàn tất và điều kiện mà các thao tác đó vẫn phải dùng được.

Chuyển hoạt động kinh doanh thành tải

Liệt kê thao tác quan trọng, kích thước đầu vào thường gặp, nhịp yêu cầu đến và yêu cầu hoàn tất. Bao gồm nhập liệu tự động, báo cáo theo lịch và lần thử lại. Phân biệt phiên đang hoạt động với yêu cầu đồng thời. Hỏi chủ nghiệp vụ giai đoạn cao điểm nào quan trọng, chẳng hạn giờ chốt điều phối hoặc đối soát cuối kỳ.

Ghi cơ cấu tải thay vì chỉ đưa một yêu cầu trung bình. Không nên coi tra cứu sản phẩm, chuyển đổi tài liệu và xuất báo cáo là lượng việc tương đương nếu chưa có bằng chứng. Xác định thao tác có thể chờ và thao tác phải xong khi khách hàng còn tương tác.

Quan sát nhu cầu cùng điểm giới hạn

Hướng dẫn giám sát của Google nêu độ trễ, lưu lượng, lỗi và mức bão hòa là bốn tín hiệu trọng yếu.[2] Dùng các nhóm này để nối nhu cầu với hành vi dịch vụ thấy được. Một biểu đồ tài nguyên đơn lẻ không nên quyết định tải thử có đáp ứng nghiệp vụ không.

AWS lưu ý yêu cầu chờ lâu có thể giữ tài nguyên hữu hạn lâu hơn, và thử lại có thể tăng tải lên dịch vụ đang gặp khó khăn.[7] Đưa các điều kiện đó vào kế hoạch thử. Một lần chạy thuận lợi với thành phần phụ thuộc phản hồi nhanh chưa cho biết hành vi khi thao tác phía sau chậm.

Chốt bằng chứng trước khi chi tiền

Yêu cầu nhà cung cấp thống nhất giả định thử và ranh giới nghiệm thu trước khi đề xuất mức tài nguyên.

• Định nghĩa loại thao tác, kích thước đầu vào và nhịp đến cao điểm thực tế.
• Bao gồm công việc theo lịch và mô hình thử lại có giới hạn.
• Đo hành vi hoàn tất cùng mức bão hòa tài nguyên.
• Thử điều kiện thành phần phụ thuộc chậm đã thống nhất.
• Nêu tải được hỗ trợ và điều kiện chưa thử.

Chọn tăng năng lực hay điều tiết nhu cầu

Thêm tài nguyên tốn tiền và có thể không xử lý được bước phải chạy tuần tự hoặc giới hạn từ bên phụ thuộc. Hoãn báo cáo không khẩn có thể bảo vệ thao tác tương tác nhưng đổi lúc nhân viên nhận kết quả. Lô nhỏ hơn có thể giảm tranh chấp nhưng tăng công điều phối. So các lựa chọn theo ưu tiên nghiệp vụ.

Dành phần dự phòng rõ ràng theo độ bất định và giả định tăng trưởng, rồi xem lại khi tải đổi. Đừng trình bày thử nghiệm thành bảo đảm cho số người dùng không giới hạn. Sản phẩm bàn giao hữu ích là phạm vi tải được hỗ trợ, có giới hạn và điều kiện đánh giá lại rõ ràng.

Ví dụ giả định: giờ chốt đơn của nhà phân phối

Trong ví dụ giả định này, nhà phân phối có nhiều người mua đăng ký nhưng hoạt động dồn trước giờ chốt điều phối. Người mua tải tệp đơn hàng lên trong lúc tác vụ đối soát tồn kho tự động cũng chạy. Nhóm mô hình hóa phần chồng lấn thay vì rải hoạt động đều cả ngày.

Thử nghiệm có kiểm soát xác định thao tác nào đáp ứng giới hạn đề xuất và thao tác nào cần đổi lịch hoặc thiết kế. Tình huống không cung cấp kết quả đo chuẩn. Nó cho thấy thêm máy chủ chỉ là một phương án khi cơ cấu tải chưa phù hợp.