Vòng lặp sự kiện so với chặn đa luồng IO

Question

Tôi đã đọc nhận xét về kiến ​​trúc máy chủ.

http://news.ycombinator.com/item?id=520077

Trong nhận xét này, người đó nói 3 điều:

1. Vòng lặp sự kiện, thời gian và một lần nữa, đã được chứng minh để thực sự tỏa sáng cho một số lượng lớn các kết nối hoạt động thấp.
2. Để so sánh, một mô hình IO chặn với các luồng hoặc quy trình đã được hiển thị, thời gian và một lần nữa, để giảm độ trễ trên cơ sở theo yêu cầu so với vòng lặp sự kiện.
3. Trên một hệ thống được tải nhẹ, sự khác biệt là không thể phân biệt được. Dưới tải, hầu hết các vòng sự kiện chọn để làm chậm, hầu hết các mô hình chặn chọn đổ tải.

Có bất kỳ điều nào trong số này đúng không?

Và cũng một bài viết ở đây với tựa đề "Tại sao sự kiện là một ý tưởng tồi (cho máy chủ cao đồng thời)"

http://www.usenix.org/events/hotos03/tech/vonbehren.html

Answer 1

Thông thường, nếu ứng dụng được mong đợi xử lý hàng triệu kết nối, bạn có thể kết hợp mô hình đa luồng với sự kiện dựa trên.

1. Trước tiên, sinh ra dưới dạng chủ đề N trong đó N == số lõi/bộ xử lý trên máy của bạn. Mỗi luồng sẽ có một danh sách các ổ cắm không đồng bộ mà nó phải xử lý.
2. Sau đó, đối với mỗi kết nối mới từ người chấp nhận, "nạp cân bằng" ổ cắm mới vào luồng bằng ổ cắm ít nhất.
3. Trong mỗi chủ đề, sử dụng mô hình dựa trên sự kiện cho tất cả các ổ cắm, để mỗi thread có thể thực sự xử lý nhiều ổ cắm "cùng một lúc".

Với phương pháp này,

1. Bạn không bao giờ đẻ trứng một triệu bài. Bạn chỉ có nhiều như hệ thống của bạn có thể xử lý.
2. Bạn sử dụng sự kiện dựa trên đa lõi thay vì một lõi đơn.

Answer 2

Không chắc chắn những gì bạn có ý nghĩa bởi "hoạt động thấp", nhưng tôi tin rằng chính yếu tố sẽ là số tiền bạn thực sự cần phải thực hiện để xử lý từng yêu cầu. Giả sử một vòng lặp sự kiện đơn luồng, không có ứng dụng khách nào khác sẽ nhận được yêu cầu của họ được xử lý trong khi bạn xử lý yêu cầu hiện tại. Nếu bạn cần phải thực hiện rất nhiều thứ để xử lý mỗi yêu cầu ("lô" có nghĩa là có một số CPU và/hoặc thời gian đáng kể) và giả sử máy của bạn thực sự có thể thực hiện đa nhiệm một cách hiệu quả (mất thời gian không có nghĩa là chờ đợi chia sẻ tài nguyên, giống như một máy CPU đơn hoặc tương tự), bạn sẽ nhận được hiệu suất tốt hơn bằng cách đa nhiệm. Đa nhiệm có thể là một mô hình chặn đa luồng, nhưng nó cũng có thể là một vòng lặp sự kiện đơn nhiệm thu thập các yêu cầu đến, nuôi chúng ra một nhà máy công nhân đa luồng để xử lý chúng lần lượt (thông qua đa nhiệm) và gửi cho bạn một phản hồi càng sớm càng tốt.

Tôi không tin rằng các kết nối chậm với khách hàng quan trọng, vì tôi tin rằng hệ điều hành sẽ xử lý hiệu quả bên ngoài ứng dụng của bạn (giả sử bạn không chặn vòng lặp sự kiện với nhiều khách hàng ban đầu đã bắt đầu yêu cầu), nhưng tôi chưa tự mình thử nghiệm điều này.