Làm thế nào để giải thích bao vây và hoặc kết quả băng ghế dự bị Apache

Question

Chúng tôi có một trang web hướng MySQL đôi khi sẽ nhận được 100 nghìn người dùng trong không gian 48 giờ, tất cả đăng nhập vào trang web và mua hàng.

Chúng tôi đang cố gắng mô phỏng loại tải này bằng cách sử dụng các công cụ như Băng ghế dự bị Apache và Siege.

Mặc dù chỉ số chính dường như với số lượng người dùng đồng thời và chúng tôi có kết quả báo cáo, chúng tôi vẫn cảm thấy như chúng tôi đang ở trong bóng tối.

Điều tôi muốn hỏi là: Chúng ta nên kiểm tra loại điều gì để dự đoán loại lưu lượng truy cập này?

50 người dùng đồng thời 1000 lần? 500 người dùng đồng thời 10 lần?

Chúng tôi đang xem xét lỗi DB, thời gian chờ apache và thời gian phản hồi. Chúng ta nên nhìn gì khác?

Đây là một câu hỏi mơ hồ và tôi biết không có câu trả lời "đúng", chúng tôi chỉ tìm kiếm một số suy nghĩ chung về cách xác định cơ sở hạ tầng của chúng tôi có thể xử lý thực tế.

Cảm ơn trước!

Answer 1

Lý tưởng nhất là bạn sẽ muốn mô hình hóa việc sử dụng của mình cho người dùng, nhưng việc tạo các phiên đồng thời được mô phỏng cho 100 nghìn người dùng thường không dễ dàng thực hiện. Nguồn tốt nhất là kiểm tra nhật ký của bạn trong giờ bận rộn nhất và thử tìm ra cách để mô hình mức tải đó.

Cơ sở dữ liệu thường là một phần cơ sở hạ tầng quan trọng, vì vậy tôi sẽ xem xét ghi lại số lượng và thời gian chờ khóa cũng như số lượng và thời lượng của các câu lệnh db.

Một mục quan trọng khác cần xem xét là độ dài hàng đợi đĩa.

Chủ yếu là quá trình tìm kiếm phản hồi chậm trên toàn bộ trang web hoặc cho các trang cụ thể và sau đó trau dồi về nguyên nhân. Vấn đề lớn nhất đối với thử nghiệm tải là khá khó khăn để kiểm tra mạng của bạn và nếu bạn có (vì hầu hết các trang web công cộng thực hiện) băng thông hạn chế thông qua ISP của bạn, điều đó có thể tạo ra vấn đề hiệu suất không được phản ánh trong tải kiểm tra.

Answer 2

Người dùng đồng thời chắc chắn là một trong những yếu tố chính - đặc biệt là áp dụng cho nhóm kết nối DB, v.v. Nhưng bạn cũng sẽ muốn xác minh rằng tỷ lệ trang (trang/giây) của các thử nghiệm cũng nằm trong phạm vi bạn chờ đợi. Nếu thời gian suy nghĩ trong testcases của bạn giảm nhiều, bạn có thể vô tình mô phỏng tỷ lệ trang cao hơn nhiều (hoặc thấp hơn) so với lưu lượng truy cập trong thế giới thực của bạn. Thời gian suy nghĩ là khoảng thời gian người dùng bỏ ra giữa các yêu cầu trang - đọc trang, điền vào biểu mẫu, v.v.

Tùy thuộc vào thông tin nào bạn có trong tay, điều này có thể giúp bạn tính số lượng người dùng đồng thời mô phỏng: Virtual User Calculators

Thời gian tải trang hoàn chỉnh mà người dùng cuối nhìn thấy thường là số liệu quan trọng nhất để đánh giá hiệu suất hệ thống. Bạn cũng sẽ muốn tìm tỷ lệ thất bại trên tất cả các giao dịch. Bạn cũng nên theo dõi các giao dịch không bao giờ hoàn thành. Một số công cụ kiểm tra không báo cáo những điều này rất tốt, cho phép người dùng mô phỏng treo vô thời hạn khi máy chủ không phản hồi ... và không báo cáo điều kiện này. Tìm các công cụ báo cáo số lượng người dùng đang chờ trên một trang hoặc giao dịch cụ thể và lượng thời gian trung bình mà những người dùng đó đang đợi.

Đối với các chỉ số phía máy chủ để tìm kiếm, công nghệ khác của bạn được xây dựng dựa trên công nghệ nào? Bạn sẽ muốn xem xét những thứ khác nhau cho ứng dụng .NET so với ứng dụng PHP.

Cuối cùng, chúng tôi thấy rất có giá trị khi xem xét hệ thống phản ứng với tải trọng tăng như thế nào, thay vì chỉ nhìn vào một mức tải duy nhất. This article đi vào chi tiết hơn.