Chúng tôi đã nói về kỹ thuật trong trong bài viết này, trong bài viết này, chúng tôi thử nghiệm HTTPS nhưng trong các tình huống thực tế hơn. Để thử nghiệm, chúng tôi đã nhận được chứng chỉ Let's Encrypt và kích hoạt tính năng nén Brotli lên 11.
Lần này chúng tôi sẽ cố gắng tái tạo kịch bản triển khai máy chủ trên VDS hoặc dưới dạng máy ảo trên máy chủ có bộ xử lý tiêu chuẩn. Vì mục đích này, một giới hạn đã được đặt ra ở:
- 25% - Tương đương với tần số ~ 1350 MHz
- 35% -1890 MHz
- 41% - 2214 MHz
- 65% - 3510 MHz
Số lượng kết nối một lần đã giảm từ 500 xuống còn 1, 3, 5, 7 và 9,
Kết quả:
Sự chậm trễ:
TTFB được đưa vào cụ thể dưới dạng thử nghiệm riêng biệt vì Công cụ HTTPD tạo người dùng mới cho từng yêu cầu riêng lẻ. Thử nghiệm này vẫn khá xa rời thực tế, vì người dùng vẫn sẽ nhấp vào một vài trang và trên thực tế, TTFP sẽ đóng vai trò chính.
Yêu cầu đầu tiên, thường là yêu cầu đầu tiên sau lần khởi động đầu tiên của máy ảo IIS, mất trung bình 120 mili giây.
Tất cả các yêu cầu tiếp theo hiển thị TTFP là 1.5 ms. Apache và Nginx đang tụt lại phía sau về mặt này. Cá nhân tác giả coi bài kiểm tra này là rõ ràng nhất và sẽ chỉ chọn người chiến thắng dựa trên nó.
Kết quả không có gì đáng ngạc nhiên vì bộ đệm IIS đã nén nội dung tĩnh và không nén nội dung đó mỗi khi được truy cập.
Thời gian dành cho mỗi khách hàng
Để đánh giá hiệu năng, chỉ cần thử nghiệm với 1 kết nối duy nhất là đủ.
Ví dụ: IIS đã hoàn thành bài kiểm tra 5000 người dùng trong 40 giây, tức là 123 yêu cầu mỗi giây.
Các biểu đồ bên dưới hiển thị thời gian cho đến khi nội dung trang web được chuyển hoàn toàn. Đây là tỷ lệ yêu cầu được hoàn thành trong một thời gian nhất định. Trong trường hợp của chúng tôi, 80% tất cả yêu cầu được xử lý trong 8 mili giây trên IIS và 4.5 mili giây trên Apache và Nginx, đồng thời 8% tất cả yêu cầu trên Apache và Nginx được hoàn thành trong khoảng thời gian lên tới 98 mili giây.
Thời gian trong đó 5000 yêu cầu được xử lý:
Thời gian trong đó 5000 yêu cầu được xử lý:
Nếu bạn có một máy ảo có CPU 3.5 GHz và 8 lõi thì hãy chọn thứ bạn muốn. Tất cả các máy chủ web đều rất giống nhau trong thử nghiệm này. Dưới đây chúng ta sẽ nói về việc chọn máy chủ web nào cho mỗi máy chủ.
Khi gặp tình huống thực tế hơn một chút, tất cả các máy chủ web sẽ đối đầu nhau.
Throughput:
Biểu đồ độ trễ so với số lượng kết nối đồng thời. Mượt mà và thấp hơn là tốt hơn. 2% cuối cùng đã bị xóa khỏi biểu đồ vì chúng sẽ khiến chúng không thể đọc được.
Bây giờ hãy xem xét tùy chọn nơi máy chủ được lưu trữ trên máy chủ ảo. Hãy lấy 4 lõi ở tốc độ 2.2 GHz và một lõi ở tốc độ 1.8 GHz.
Làm thế nào để mở rộng quy mô
Nếu bạn đã từng thấy đặc tính dòng điện-điện áp của triode chân không, pentode, v.v. trông như thế nào thì những biểu đồ này sẽ quen thuộc với bạn. Đây là những gì chúng tôi đang cố gắng nắm bắt - sự bão hòa. Giới hạn là dù bạn có ném bao nhiêu lõi đi chăng nữa thì hiệu suất cũng sẽ không tăng lên đáng kể.
Trước đây, toàn bộ thử thách là xử lý 98% yêu cầu với độ trễ thấp nhất cho tất cả các yêu cầu, giữ cho đường cong càng phẳng càng tốt. Bây giờ, bằng cách xây dựng một đường cong khác, chúng ta sẽ tìm ra điểm vận hành tối ưu cho từng máy chủ.
Để thực hiện việc này, hãy lấy chỉ báo Yêu cầu mỗi giây (RPR). Ngang là tần số, dọc là số lượng yêu cầu được xử lý mỗi giây, dòng là số lõi.
Hiển thị mối tương quan về mức độ Nginx xử lý các yêu cầu lần lượt. 8 lõi hoạt động tốt hơn trong thử nghiệm này.
Biểu đồ này cho thấy rõ Nginx hoạt động tốt hơn (không nhiều) như thế nào trên một lõi đơn. Nếu bạn có Nginx, bạn nên cân nhắc việc giảm số lượng lõi xuống còn một nếu bạn chỉ lưu trữ các lõi tĩnh.
IIS, mặc dù có TTFB thấp nhất theo DevTools trong Chrome, nhưng vẫn để thua cả Nginx và Apache trong một cuộc chiến nghiêm túc với bài kiểm tra căng thẳng từ Apache Foundation.
Tất cả độ cong của đồ thị đều được tái tạo bằng sắt.
Một số loại kết luận:
Có, Apache hoạt động kém hơn trên lõi 1 và 8, nhưng hoạt động tốt hơn một chút trên lõi 4.
Có, Nginx trên 8 lõi xử lý các yêu cầu lần lượt tốt hơn, trên lõi 1 và 4, đồng thời hoạt động kém hơn khi có nhiều kết nối.
Có, IIS ưu tiên 4 lõi cho khối lượng công việc đa luồng và ưu tiên 8 lõi cho khối lượng công việc đơn luồng. Cuối cùng, IIS nhanh hơn một chút so với những máy chủ khác trên 8 lõi ở mức tải cao, mặc dù tất cả các máy chủ đều ngang bằng.
Đây không phải là lỗi đo lường, sai số ở đây không quá +-1ms. có độ trễ và không quá +- 2-3 yêu cầu mỗi giây đối với RPR.
Kết quả trong đó 8 lõi hoạt động kém hơn hoàn toàn không có gì đáng ngạc nhiên, nhiều lõi và SMT/Siêu phân luồng làm giảm hiệu suất đáng kể nếu chúng ta có khung thời gian mà chúng ta phải hoàn thành toàn bộ quy trình.
Nguồn: www.habr.com