Điều này có chứng tỏ sự tắc nghẽn băng thông mạng?


14

Tôi đã giả định không chính xác rằng thử nghiệm AB nội bộ của tôi có nghĩa là máy chủ của tôi có thể xử lý 1k lượt truy cập đồng thời @ 3k lượt truy cập mỗi giây.

Lý thuyết của tôi tại thời điểm này là mạng là nút cổ chai. Máy chủ không thể gửi đủ dữ liệu đủ nhanh.

Thử nghiệm bên ngoài từ blitz.io ở mức 1k đồng thời cho thấy số lần truy cập / s của tôi bị giảm ở mức 180, với các trang mất nhiều thời gian hơn và lâu hơn để phản hồi vì máy chủ chỉ có thể trả về 180 mỗi giây.

nhập mô tả hình ảnh ở đây

Tôi đã phục vụ một tệp trống từ nginx và đã chuẩn bị nó: nó tỷ lệ 1: 1 với sự tương tranh.

nhập mô tả hình ảnh ở đây

Bây giờ để loại trừ các tắc nghẽn IO / memcached (nginx thường lấy từ memcached), tôi cung cấp một phiên bản tĩnh của trang được lưu trong bộ nhớ cache từ hệ thống tệp.

nhập mô tả hình ảnh ở đây

Kết quả rất giống với thử nghiệm ban đầu của tôi; Tôi bị giới hạn ở khoảng 180 RPS.

Việc chia đôi trang HTML mang lại cho tôi gấp đôi RPS, do đó chắc chắn nó bị giới hạn bởi kích thước của trang.

nhập mô tả hình ảnh ở đây

Nếu tôi nội bộ ApacheBench từ máy chủ cục bộ, tôi sẽ nhận được kết quả nhất quán khoảng 4k RPS trên cả Trang đầy đủ và Nửa trang, với tốc độ truyền cao. Tốc độ truyền: 62586,14 [Kbytes / giây] đã nhận được

Nếu tôi AB từ một máy chủ bên ngoài, tôi nhận được khoảng 180RPS - giống như kết quả blitz.io.

Làm thế nào để tôi biết đó không phải là điều tiết lưu ý?

Nếu tôi điểm chuẩn từ nhiều máy chủ bên ngoài, tất cả các kết quả sẽ trở nên kém khiến tôi tin rằng vấn đề nằm ở lưu lượng truy cập của máy chủ MY, không phải là vấn đề về tốc độ tải xuống với máy chủ điểm chuẩn của tôi / blitz.io.

Vì vậy, tôi trở lại kết luận của mình rằng máy chủ của tôi không thể gửi dữ liệu đủ nhanh.

Tôi có đúng không Có những cách khác để giải thích dữ liệu này? Là giải pháp / tối ưu hóa để thiết lập nhiều máy chủ + cân bằng tải, mỗi máy có thể phục vụ 180 lần truy cập mỗi giây?

Tôi còn khá mới với tối ưu hóa máy chủ, vì vậy tôi đánh giá cao bất kỳ xác nhận nào diễn giải dữ liệu này.


Giao thông đi

Dưới đây là thông tin thêm về băng thông đi: Biểu đồ mạng hiển thị đầu ra tối đa 16 Mb / giây: 16 megabit / giây. Nghe có vẻ không nhiều lắm.

Do một gợi ý về điều chỉnh, tôi đã xem xét điều này và thấy rằng linode có giới hạn 50mbps (rõ ràng là tôi thậm chí không gần với việc nhấn, rõ ràng). Tôi đã tăng nó lên 100mbps.

Vì linode giới hạn lưu lượng truy cập của tôi và tôi thậm chí không nhấn nó, điều này có nghĩa là máy chủ của tôi thực sự có khả năng xuất tới 100mbps nhưng bị giới hạn bởi một số nút cổ chai nội bộ khác? Tôi chỉ không hiểu làm thế nào các mạng ở quy mô lớn này hoạt động; họ có thể gửi dữ liệu nhanh như họ có thể đọc từ ổ cứng không? Là ống mạng lớn?

nhập mô tả hình ảnh ở đây


Tóm lại là

1: Dựa trên những điều trên, tôi nghĩ rằng tôi chắc chắn có thể tăng 180RPS của mình bằng cách thêm bộ cân bằng tải nginx trên đầu thiết lập máy chủ đa nginx ở chính xác 180RPS cho mỗi máy chủ phía sau LB.

2: Nếu linode có giới hạn 50 / 100mbit mà tôi hoàn toàn không đạt được, thì tôi phải làm gì đó để đạt giới hạn đó với thiết lập máy chủ duy nhất của mình. Nếu tôi có thể đọc / truyền dữ liệu đủ nhanh cục bộ và thậm chí cả hai đều có giới hạn 50mbit / 100mbit, thì phải có một nút cổ chai bên trong không cho phép tôi chạm vào các nắp đó mà tôi không chắc chắn cách phát hiện. Chính xác?

Tôi nhận ra câu hỏi bây giờ rất lớn và mơ hồ, nhưng tôi không chắc làm thế nào để cô đọng nó. Bất kỳ đầu vào được đánh giá cao trên bất kỳ kết luận tôi đã thực hiện.


1
Để kiểm tra xem đó có phải là sự cố về băng thông hay không, bạn có thể làm cho trang html của mình lớn hơn nhiều để đạt được cùng một băng thông với ít yêu cầu hơn. Nếu trang của bạn lớn hơn 5 MB, thì bạn sẽ có thể đạt được thông lượng tương tự chỉ với một vài yêu cầu / giây, điều này sẽ có ít chi phí hơn rất nhiều và do đó giúp bạn tiến gần hơn đến giới hạn băng thông thực tế của mình.
brain99

Tôi vừa thử một trang có kích thước chính xác gấp 10 lần. RPS của tôi tương quan trực tiếp đến kích thước trang. Lớn hơn gấp 10 lần == 18RPS. 1x == 180. Tôi thực sự nghĩ rằng điều này đáng ngờ là gần 50mbits. Tôi nghĩ rằng có khả năng giám sát trạng thái của linode tối đa 24mbits có thể sai và tôi thực sự đã đạt được giới hạn của họ. Tôi đang yêu cầu tăng trở lại và sẽ báo cáo lại.
Yuji Tomita

Câu trả lời:


5

Vấn đề là tôi giả định rằng các đỉnh đồ thị linode.com là các đỉnh thực sự. Hóa ra đồ thị sử dụng các điểm dữ liệu trung bình 5 phút, do đó, đỉnh của tôi dường như là 24mbits trong khi thực tế tôi đã đạt đến giới hạn 50mbit.

Bây giờ họ đã tăng nó lên 100mbits, điểm chuẩn của tôi ngay lập tức tăng lên đến giới hạn lưu lượng truy cập mới.

Giá như tôi đã nhận thấy điều đó sớm hơn! Rất nhiều lý do của tôi xoay quanh ý tưởng rằng tôi đã không đạt giới hạn lưu lượng truy cập đi do biểu đồ đó.

Bây giờ, tôi đạt cực đại ở mức 370 yêu cầu mỗi giây, tức là dưới 100mbps tại thời điểm tôi bắt đầu nhận được "tồn đọng" các yêu cầu và thời gian phản hồi bắt đầu tăng lên.

nhập mô tả hình ảnh ở đây

Bây giờ tôi có thể tăng đồng thời tối đa bằng cách thu nhỏ trang; với gzip được kích hoạt tôi nhận được 600RPS.

nhập mô tả hình ảnh ở đây

Tôi vẫn gặp vấn đề khi đột nhiên lên đến đỉnh điểm và tồn đọng các yêu cầu đang chờ xử lý (bị giới hạn bởi băng thông) bắt đầu tích lũy, nhưng đó có vẻ như là một câu hỏi khác.

nhập mô tả hình ảnh ở đây

Đó là một bài học tuyệt vời về tối ưu hóa / đọc dữ liệu này / thu hẹp các vấn đề có thể xảy ra. Cảm ơn rất nhiều vì đầu vào của bạn!


4

Bây giờ hơi muộn khi bạn phát hiện ra điều đó ... nhưng có lẽ thỉnh thoảng bạn nên xem xét việc đọc blog ServerFault.

Tôi đang suy nghĩ cụ thể về bài đăng này , nơi họ thảo luận về lý do tại sao có một khoảng thời gian bỏ phiếu một giây không cắt nó theo thời gian, liên quan đến một vấn đề rất giống với vấn đề bạn gặp phải ..

Chúng tôi phát hiện ra rằng chúng tôi đã loại bỏ các gói khá thường xuyên trên các giao diện 1 Gbit / s với tốc độ chỉ 10-30 MBit / giây làm tổn hại đến hiệu suất của chúng tôi. Điều này là do tốc độ 10-30 MBit / s thực sự là số bit được truyền trong mỗi 5 phút được chuyển đổi thành tốc độ một giây. Khi chúng tôi tiến gần hơn với Wireshark và sử dụng đồ thị IO một mili giây, chúng tôi thấy chúng tôi sẽ thường xuyên phá vỡ tốc độ 1 Mbit mỗi mili giây của giao diện 1 Gbit / s.

Chắc chắn làm tôi suy nghĩ. Và tôi chỉ biết rằng tôi đang làm phiền rằng một trong những SA khác tại cửa hàng của tôi là cơ hội đầu tiên tôi có được, và sẽ trông cực kỳ xuất sắc và nhận thức khi chúng tôi gặp phải vấn đề này.

Ai biết được, tôi thậm chí có thể để một số trong số họ trong bí mật. :)


Điểm tốt! Thật thú vị khi họ cũng đưa ra biểu đồ 5 phút @ 1 giây ... Tôi tương đối thoải mái với dữ liệu vì thử nghiệm đồng thời 1k của tôi đã là một trường hợp xấu nhất (tôi nghĩ ..). ~ 600 người dùng tải một trang mỗi giây == ~ 2m lượt truy cập mỗi giờ, mà chúng tôi thậm chí không đến gần. Tôi chỉ không muốn sa lầy trong vài phút đầu tiên của một đột biến.
Yuji Tomita

0

Nó có thể bị giới hạn bởi mạng, nhưng không nhất thiết chỉ là một câu hỏi về băng thông. Độ trễ của đơn vị kiểm tra từ xa của bạn sẽ có ảnh hưởng đến số lượng kết nối đang chờ xử lý tại bất kỳ thời điểm nào (chờ 50ms cho các xác nhận khác rất nhiều so với 0,55 cục bộ) cũng như việc đàm phán và ổn định kích thước cửa sổ khi quá trình kết nối diễn ra. Bạn cũng có khả năng bị mất một số lượng gói tin - như là một chức năng tắc nghẽn hoặc là cơ chế giới hạn băng thông trên một phần của nhà cung cấp dịch vụ của bạn (hoặc những người ngược dòng).

Tôi muốn đề xuất loại bỏ càng nhiều càng tốt khỏi phương trình để vẽ đường cơ sở hợp lý. Đo băng thông cao nhất, độ trễ và mất gói từ máy chủ của bạn đến một vài điểm trên Internet nói chung. Không thể nghe được, hãy thử tìm kiếm "Kiểm tra lưu lượng truy cập Voip" hoặc tương tự. Một số nhà cung cấp dịch vụ VOIP có các ứng dụng có thể đo lường các loại mẫu này (hai chiều) với mức độ chính xác hợp lý. Khi bạn có một số dữ liệu thực nghiệm hợp lệ về tốc độ hữu ích thực tế của liên kết thì kết quả của bạn có thể được xác thực.

Ngoài các kiểm tra băng thông, có thể hữu ích khi xem xét một gói chụp lưu lượng truy cập web phụ để tìm kiếm số lượng truyền lại quá mức cũng như đo thời gian rõ ràng mà máy chủ của bạn đang thực hiện để đáp ứng yêu cầu (.. nếu điều này giá trị đang tăng đáng kể như là một hàm của số lượng kết nối, đây là một đầu mối lớn).

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.