Nginx được đặt trước một kiến ​​trúc microservice mà chúng tôi không có bất kỳ thông tin chi tiết nào. Chúng tôi truy xuất các chỉ số được hiển thị bởi trạng thái sơ khai của http và muốn tính toán một chỉ báo về hiệu suất nền tảng: Chúng tôi không thể sử dụng độ trễ khi kiểm tra tải vì chúng tôi muốn so sánh các trang web khác nhau về mặt địa lý.

Những gì chúng tôi đã cố gắng cho đến nay:

  • Tính toán tổng số yêu cầu trên một đơn vị thời gian. Vấn đề: nó không phản ánh hiệu suất, tất cả các trang web xử lý cùng một lượng yêu cầu (100req trên 100ms)
  • Sử dụng thước đo kết nối đang chờ *

* Với chỉ số này, chúng tôi quan sát các hành vi khác nhau. Hai thái cực là:

2012 server (E5-2620 v1, 24 threads) : an average of 68,62 Waiting connections per 100ms

2021 server (AMD EPYC 7642, 96 threads) : an average of 91,96 Waiting connections per 100ms

Câu hỏi đầu tiên. Có vẻ như thước đo nên được đọc là "càng cao càng tốt". Tại sao? Tài liệu không cung cấp thông tin chi tiết nhưng theo hiểu biết của chúng tôi, một kết nối đang chờ câu trả lời sẽ xuất hiện ở đây. Hay thước đo này chỉ bao gồm các kết nối không hoạt động (tức là những kết nối đã được phục vụ)?

Câu hỏi thứ hai. Trong cùng một bài kiểm tra tải, các chỉ số kết nối được chấp nhận / xử lý cao hơn nhiều trên máy chủ gần đây nhất (khoảng gấp đôi). Tại sao? Cả hai đều phục vụ cùng một số lượng yêu cầu được gửi bởi một nhóm 100 kết nối. Những gì chúng ta thấy là số lượng kết nối được xử lý tiến triển rất nhanh ngay từ đầu, lên đến một giá trị trần khác tùy thuộc vào kiến ​​trúc và sau đó, tiến trình này khá tuyến tính. Chúng tôi không thể tìm thấy bất kỳ lời giải thích nào về hành vi này được hiển thị trên biểu đồ này: biểu đồ về các kết nối được xử lý

answer

We cannot use latency on a load test as we want to compare geographically different sites.

Có thật không? Thời gian phản hồi cho các yêu cầu là một số liệu thực sự tương ứng với mức độ chậm của một thứ đối với người dùng. Các khu vực địa lý khác nhau có thể dẫn đến phân phối thống kê phức tạp hơn, nhưng nó vẫn hữu ích để phân tích.

[Waiting connections] gauge should be read as "the higher the better". Why?

Các kết nối đang hoạt động Đọc và Viết đang thực hiện I / O, đang thực hiện công việc. Chờ đợi là giữ bí danh, đợi khách hàng, sau khi họ đã hoàn thành một yêu cầu.

Ở cùng các yêu cầu trên mỗi cấp độ thứ hai, đọc và ghi thấp hơn là tốt, vì điều đó liên quan đến các kết nối được phục vụ nhanh chóng. Có lẽ điều đó có nghĩa là máy khách phải chờ đợi nhiều hơn, do đó số lượng chờ cao hơn, nhưng có giới hạn về số lượng kết nối.

Second question. On a same load test, accepted/handled connection metrics are much higher on the most recent server (around the double). Why?

Vài giây đầu tiên của cả hai kết nối theo thời gian hơi khác thường, gần như ngay lập tức. Tôi không hoàn toàn rõ ràng về lý do tại sao điều này xảy ra, nhưng có lẽ nginx đã chạy lâu hơn trước khi kiểm tra nên bộ đếm cao hơn.

Tôi sẽ bỏ qua vài giây đầu tiên như một màn khởi động. Và có thể vẽ biểu đồ các yêu cầu trên giây theo thời gian, vì có thể dễ dàng hơn để xem các xu hướng về những gì nên là một đường thẳng.