Apache Benchmark - concurrency và số yêu cầu

Question

Tài liệu chuẩn cho biết đồng thời là số lượng yêu cầu được thực hiện đồng thời, trong khi số lượng yêu cầu là tổng số yêu cầu. Điều tôi đang tự hỏi là, nếu tôi đặt 100 yêu cầu ở mức đồng thời là 20, điều đó có nghĩa là 5 lần kiểm tra 20 yêu cầu cùng một lúc, hoặc 100 thử nghiệm của 20 yêu cầu cùng một lúc? Tôi giả định tùy chọn thứ hai, vì những con số ví dụ trích dẫn dưới đây ..

Tôi đang tự hỏi vì tôi thường xuyên xem kết quả như thế này trên một số blog thử nghiệm:

Complete requests: 1000000 
Failed requests: 2617614 

Điều này có vẻ không hợp lý, vì số lượng yêu cầu không thành công cao hơn tổng số yêu cầu.

Edit: các trang web hiển thị những con số nói trên: http://zgadzaj.com/benchmarking-nodejs-basic-performance-tests-against-apache-php

HOẶC nó có thể là nó giữ cố gắng cho đến khi nó đạt đến một triệu thành công? Hm ...

Answer 1

Nó có nghĩa là một thử nghiệm duy nhất với tổng số 100 yêu cầu, giữ 20 yêu cầu luôn mở. Tôi nghĩ rằng quan niệm sai lầm bạn có là yêu cầu tất cả mất cùng một lượng thời gian, mà hầu như không bao giờ là trường hợp. Thay vì yêu cầu phát hành theo lô 20, ab chỉ đơn giản là bắt đầu với 20 yêu cầu và đưa ra yêu cầu mới mỗi lần yêu cầu hiện có kết thúc.

Ví dụ, thử nghiệm với ab -n 10 -c 3 sẽ bắt đầu with3 yêu cầu đồng thời:

[1, 2, 3] 

Hãy nói rằng # 2 kết thúc đầu tiên, ab thay thế nó với một thứ tư:

[1, 4, 3] 

... sau đó # 1 có thể hoàn thành, được thay thế bằng một phần năm:

[5, 4, 3] 

... Sau đó # 3 kết thúc:

[5, 4, 6] 

... và cứ như vậy, cho đến khi yêu cầu tổng cộng 10 yêu cầu đã được thực hiện. (Khi các yêu cầu 8, 9 và 10 hoàn thành, các lần chạm đồng thời được tắt tới 0 tất nhiên.)

Có ý nghĩa?

Đối với câu hỏi của bạn về lý do tại sao bạn thấy kết quả có nhiều lỗi hơn tổng số yêu cầu ... Tôi không biết câu trả lời cho điều đó. Tôi không thể nói rằng tôi đã nhìn thấy điều đó. Bạn có thể gửi liên kết hoặc các trường hợp kiểm tra cho thấy điều này?

Cập nhật: Trong quá trình tìm the source, ab theo dõi bốn loại lỗi được trình bày chi tiết bên dưới "yêu cầu Không: ..." dòng:

• Connect - (err_conn trong nguồn) Tăng lên khi ab thất bại để thiết lập kết nối HTTP
• Nhận - (err_recv trong nguồn) tăng lên khi ab không đọc của kết nối không
• chiều dài - (err_length trong nguồn) tăng lên khi chiều dài phản ứng khác với chiều dài của tốt đầu tiên kính trọng onse nhận được.
• Exceptions - (? Ví dụ như kết nối được giết bởi máy chủ) (err_except trong nguồn) Tăng lên khi ab thấy một lỗi khi bỏ phiếu các ổ cắm kết nối

Logic xung quanh khi những xảy ra và cách thức chúng được tính (và tổng số bad được theo dõi) là, cần thiết, phức tạp một chút. Có vẻ như phiên bản hiện tại của ab chỉ nên đếm một lần thất bại một lần cho mỗi yêu cầu, nhưng có lẽ tác giả của bài viết đó đang sử dụng một phiên bản trước đó bằng cách nào đó đếm nhiều hơn một? Đó là dự đoán tốt nhất của tôi.

Nếu bạn có thể tạo lại hành vi, chắc chắn là file a bug.

Answer 2

Tôi không thấy gì sai. Các yêu cầu không thành công có thể tăng nhiều lỗi. Đó là cách hoạt động của ab.

Có nhiều bộ đệm được khai báo tĩnh khác nhau có độ dài cố định. Kết hợp với phân tích cú pháp lười biếng đối số dòng lệnh, tiêu đề phản hồi từ máy chủ và các đầu vào bên ngoài khác, điều này có thể khiến bạn bị lỗi.

Bạn có thể nhận thấy ví dụ rằng các kết quả của nút trước đó có số lượng tương tự cho 3 trong số các bộ đếm lỗi. Hầu hết có lẽ, từ 100 000 yêu cầu chỉ thực hiện 8409 không thành công và không phải là 25227.

Receive: 8409, Length: 8409, Exceptions: 8409