Xác định số đo thực tế của yêu cầu mỗi giây cho máy chủ web

15

Tôi đang thiết lập ngăn xếp nginx và tối ưu hóa cấu hình trước khi đi vào hoạt động. Chạy ab để kiểm tra căng thẳng máy, tôi đã thất vọng khi thấy mọi thứ đứng đầu với 150 yêu cầu mỗi giây với số lượng yêu cầu đáng kể mất> 1 giây để trả về. Kỳ lạ thay, chính chiếc máy thậm chí còn không thở được.

Cuối cùng tôi đã nghĩ đến việc ping hộp và thấy thời gian ping khoảng 100-125 ms. (Máy, làm tôi ngạc nhiên, là trên toàn quốc). Vì vậy, có vẻ như độ trễ mạng đang chi phối thử nghiệm của tôi. Chạy các thử nghiệm tương tự từ một máy trên cùng một mạng với máy chủ (thời gian ping <1ms) và tôi thấy> 5000 yêu cầu mỗi giây, phù hợp hơn với những gì tôi mong đợi từ máy.

Nhưng điều này khiến tôi suy nghĩ: Làm cách nào để xác định và báo cáo số đo yêu cầu "thực tế" mỗi giây cho máy chủ web? Bạn luôn thấy các khiếu nại về hiệu suất, nhưng không nên xem xét độ trễ mạng? Chắc chắn tôi có thể phục vụ 5000 yêu cầu mỗi giây cho một máy bên cạnh máy chủ, nhưng không phục vụ cho một máy trên toàn quốc. Nếu tôi có nhiều kết nối chậm, cuối cùng chúng sẽ ảnh hưởng đến hiệu suất máy chủ của tôi, phải không? Hay tôi đang nghĩ về điều này tất cả sai?

Hãy tha thứ cho tôi nếu đây là kỹ thuật mạng 101 thứ. Tôi là một nhà phát triển thương mại.

Cập nhật: Đã chỉnh sửa cho rõ ràng.

— Don
nguồn

abcó một tùy chọn đồng thời. Bạn đã đặt nó vào cái gì? Ngoài ra, nếu bạn đang kiểm tra từ kết nối ADSL trong nước, thử nghiệm có thể bị chi phối bởi băng thông của bạn và sẽ không kiểm tra bất cứ điều gì trên máy chủ.

— Ladadadada

Tôi quen thuộc với tùy chọn đồng thời của ab và đã thử một loạt các giá trị để khám phá các giới hạn của hộp. Như tôi đã viết ở trên, tôi hiểu rằng các thử nghiệm ban đầu của tôi bị chi phối bởi mạng và không phản ánh khả năng của máy chủ. Nhưng câu hỏi của tôi vẫn là: Hầu hết mọi người chạy thử nghiệm từ đâu để có được số liệu thực tế? Các thử nghiệm chạy từ một hộp trên cùng một mạng với máy chủ (thực sự loại bỏ bất kỳ độ trễ mạng nào ra khỏi phương trình) trả về những con số tuyệt vời, nhưng chúng dường như không phải là những con số "công bằng" vì người dùng thực sẽ đến từ bên ngoài mạng.

— Don

Các thử nghiệm chạy từ cùng một mạng trên thực tế có thể 'công bằng' hơn vì về cơ bản chúng bỏ qua mạng. Người dùng của bạn có khả năng tất cả trên các mạng khác nhau - vì vậy băng thông tổng hợp của tất cả các mạng đó sẽ dễ dàng vượt quá băng thông có sẵn của máy chủ của bạn. Do đó, khi xem xét tất cả người dùng, nút cổ chai là do khả năng của máy chủ - trong khi xem xét một người dùng riêng lẻ, nút cổ chai có thể là băng thông của một người dùng. (Thử nghiệm lý tưởng, có lẽ, sẽ được chạy từ nhiều địa điểm từ xa để mô phỏng tốt nhất các trường hợp thực tế, mặc dù, hầu hết các trường hợp không cần điều đó).

— cyberx86

"Xem xét tất cả người dùng với nhau, do đó, nút cổ chai là khả năng của máy chủ" - điều đó có ý nghĩa và có vẻ như là cách đúng đắn để suy nghĩ về nó. Tôi cho rằng máy chủ có thể ngồi phía sau thiết bị mạng xảo quyệt, hạn chế tốc độ phản hồi của nó với thế giới bên ngoài, nhưng đó không thực sự là vấn đề của máy chủ và cần được giải quyết riêng. Một cái gì đó như Pingdom có thể được sử dụng để chạy thử nghiệm lý tưởng, tôi cho rằng.

— Don

3

Nếu bạn quan tâm đến hiệu suất của máy chủ khi được truy cập từ một nơi nào đó trên thế giới, hãy nhờ một người bạn ở đâu đó trên thế giới (nên có băng thông tốt) để cài đặt sproxy + bao vây trên hộp linux của anh ấy. Chỉ cần tải về, cấu hình, thực hiện. Các công cụ này là nhỏ, chúng biên dịch trong vòng vài giây.

Đầu tiên, bắt đầu sproxytrên hộp linux. Theo mặc định, nó sẽ chạy trên port 9001 trên localhost (127.0.0.1). Nếu bạn muốn truy cập nó từ bên ngoài, chỉ cần truyền địa chỉ IP bên ngoài làm tham số.
Bây giờ kết nối với sproxy bằng cách đặt trình duyệt của bạn sử dụng ip và cổng này làm proxy cho HTTP. Tất cả mọi thứ bạn làm từ bây giờ được ghi lại bởi sproxy và có thể được phát lại sau đó. Bây giờ hãy lướt xung quanh trang web của bạn, làm những việc mà khách hàng của bạn sẽ làm và cố gắng làm những việc "đắt tiền" sử dụng máy chủ của bạn.
Khi hoàn tất, kết thúc sproxy bằng cách nhấn CTRL ^ C. Nó ghi lại hành động của bạn để $HOME/urls.txt. Di chuyển tệp đến nơi bao vây cư trú. Để bắt đầu thử nghiệm căng thẳng, chạy siege -f urls.txt -d NUM -c NUM. dlà viết tắt của độ trễ giữa các yêu cầu, khi thực hiện kiểm tra hiệu suất, sử dụng 1 (giây).clà viết tắt của số lượng người dùng đồng thời mô phỏng. Chọn theo ý muốn, nhưng bắt đầu thấp. Siege sẽ cho bạn thấy số lượng giao dịch mỗi giây, không ổn định, thời gian yêu cầu trung bình mất bao lâu, v.v ... Đây là một công cụ mạnh mẽ và dễ sử dụng.
Nếu bạn cần thêm thông tin về các tham số (có rất nhiều), hãy kiểm tra hướng dẫn bao vây một hướng dẫn sử dụng sproxy

Để có kết quả thực tế hơn, hãy để nhiều người kiểm tra máy chủ của bạn từ nhiều quốc gia khác nhau và để họ gửi cho bạn số liệu thống kê.

— Chất xơ
nguồn

2

Các yêu cầu thực tế / biện pháp giây nên được lấy từ nhật ký truy cập. IMO, độ trễ yêu cầu không liên quan gì đến tải máy chủ, vì máy chủ xử lý tất cả các yêu cầu ở cùng tốc độ không phân biệt nguồn gốc của chúng.

— ejaenv
nguồn

1

Cân nhắc sử dụng các dịch vụ như Soasta Cloudtest . Với nó, bạn có thể nhận được các báo cáo khá chi tiết về các thử nghiệm của mình và bạn có thể chạy thử nghiệm hiệu suất từ các nhà cung cấp ảo / đám mây công cộng khác nhau. Bạn có thể định cấu hình mức độ khó và trong bao lâu bạn muốn đập máy chủ của mình. Họ cũng có một phiên bản " lite " miễn phí để bạn có thể xem những gì nó có thể làm trước khi cam kết bất kỳ khoản tiền nào.

— Mxx
nguồn