Có thể nói, trong bài viết này, chúng ta sẽ thử sức mình với kỹ thuật đảo ngược. Chúng tôi sẽ sử dụng bàn tay bẩn thỉu của mình để điều khiển từng máy chủ web, khai thác chúng theo những cách mà không ai có thể khai thác được.
Thử nghiệm này là phép đo một con ngựa hình cầu trong chân không, không gì khác hơn là dữ liệu thu được và hiện tại chúng tôi không biết phải làm gì với nó.
Phương pháp luận
Hệ điều hành cho Nginx và Apache là Ubuntu 18.04 LTS, dành cho IIS Windows Server Core 2019. Trước khi thử nghiệm, tất cả các hệ điều hành đều nhận được bản cập nhật mới nhất kể từ ngày 04.12.2019 tháng XNUMX năm XNUMX.
Các thử nghiệm được thực hiện độc quyền qua HTTP. Mỗi máy chủ web chạy cùng một trang, một mẫu Jekyll miễn phí từ Codrops. . Mỗi máy chủ web đều bị tắt tính năng nén gzip.
Kiểm tra thông lượng được thực hiện với các công cụ Httpd với các đối số:
ab -n 50000 -c 500 http://192.168.76.204:80/Máy chủ bị giới hạn ở 10, 5 và 1 phần trăm lõi trên 8, 4 và một lõi. Băng ghế thử nghiệm là một máy tính có tốc độ 9900K@5400 MHz, có nghĩa là máy chủ nhận giới hạn 10% sẽ nhận được khoảng 540 MHz mỗi lõi.
Thử nghiệm TTFB được thực hiện khi máy chủ khởi động lần đầu và đo bằng DevTools; sau khi nhận được kết quả, máy chủ đã bị tắt và quay trở lại điểm kiểm tra trước đó để loại bỏ sự xuất hiện của bất kỳ loại bộ nhớ đệm nào.
Người kiểm tra và máy chủ web ở trên cùng một máy chủ và trên cùng một bộ chuyển mạch ảo.
Để đánh giá ngay hệ thống con đĩa, kết quả của điểm chuẩn ATTO và CrystalDIskMark để có ý tưởng về các điểm nghẽn.
Dữ liệu lấy từ máy ảo:
Kết quả:
TTFB:
TTFB trung bình cho IIS là nhỏ nhất, 0,5 mili giây, so với 1,4 mili giây đối với Apache và 4 mili giây đối với Nginx.
Throughput:
Trước tiên, hãy xem mỗi máy chủ có quy mô tốt như thế nào dựa trên số lượng lõi.
Biểu đồ hiển thị số lượng cuộc gọi của người thử nghiệm đến máy chủ web và độ trễ. Biểu đồ cho thấy NGINX đã xử lý 98% tất cả các yêu cầu, phân phối trang web trong 20 mili giây hoặc ít hơn. IIS, giống như Apache, đã hoàn thành 5% cuối cùng của tất cả các cuộc gọi lần lượt trong 76 mili giây và 14 mili giây.
Biểu đồ hiển thị thời gian xử lý trung bình cho một yêu cầu trong quá trình kiểm tra sức chịu đựng.
Như bạn có thể thấy từ biểu đồ, IIS đã loại bỏ cả Apache và Nginx, làm chậm đáng kể khi tải cao.
IIS rõ ràng ưu tiên 4 lõi hơn XNUMX, cho thấy độ trễ thấp hơn trên XNUMX, nhưng cũng không ưu tiên nhiều lõi.
NGINX có quy mô tốt trên tất cả 8 lõi và đối với Apache, kịch bản lõi đơn dường như là lựa chọn tốt nhất.
Khả năng mở rộng:
nginx:
Bây giờ chúng ta hãy xem khả năng mở rộng về mặt tần số và số lượng lõi.
Nginx đã không vượt qua các bài kiểm tra với giới hạn 1% cho lõi 4 và 1; khi vượt quá 2000 yêu cầu, nó đã chấm dứt kết nối với người kiểm tra.
Apache:
Apache, giống như Nginx, sau khi xử lý 2500 yêu cầu, đã từ bỏ và đóng kết nối. Apache đã thất bại trong bài kiểm tra trên 8, 4 và 1 lõi với giới hạn 1%, nhưng ngoài ra, nó cũng thất bại trong bài kiểm tra với giới hạn 5% trên một lõi, tệ hơn cả Nginx
IIS:
Trong quá trình thử nghiệm, IIS đã tích lũy một hàng yêu cầu khổng lồ nhưng đã xử lý từng yêu cầu đó. Rõ ràng là không có thời gian chờ nào được đặt để xử lý yêu cầu.
Biểu đồ hiển thị thời gian cần thiết để hoàn thành bài kiểm tra. Các cấu hình thử nghiệm hoàn toàn vô lý đã bị loại bỏ. Sơ đồ cho thấy IIS đòi hỏi khắt khe như thế nào khi nói đến phần cứng và NGINX tuyệt vời như thế nào.
Khả năng mở rộng từ đĩa:
nginx:
Bây giờ chúng ta hãy xem khả năng mở rộng về mặt tần số, số lượng lõi và tốc độ ổ đĩa.
Lần này Nginx đã thất bại 4 bài kiểm tra thay vì hai.
Apache:
Apache đã thất bại với số lần thử nghiệm tương tự như lần trước.
IIS:
IIS hiển thị một biểu đồ gần như giống hệt nhau, như thể không có hạn chế về ổ đĩa. Nhìn chung, đồ họa của tất cả các máy chủ không thay đổi nhiều, có nghĩa là mỗi máy chủ đều lưu dữ liệu tĩnh vào bộ nhớ đệm trong RAM và phục vụ dữ liệu đó từ đó. Ở đây chúng ta thấy nút thắt cổ chai chính - chính máy chủ web.
Còn quá sớm để đưa ra kết luận dựa trên thử nghiệm này; chúng tôi chưa thử nghiệm HTTPS, nén và HTTP/2 với chứng chỉ trực tiếp từ Let's Encrypt. Chúng ta sẽ nói về điều này trong bài viết tiếp theo.
Nguồn: www.habr.com