Mô hình đề xuất cho mỗi yêu cầu có nhanh hơn I/O không chặn không?

Question

Tôi nhớ cách đây 2 hoặc 3 năm để đọc một vài bài báo mà mọi người cho rằng các thư viện luồng hiện đại đã trở nên tốt đến nỗi các máy chủ theo yêu cầu sẽ không chỉ dễ viết hơn các máy chủ không chặn mà chúng sẽ nhanh hơn , quá. Tôi tin rằng điều này thậm chí đã được chứng minh trong Java với một JVM đã ánh xạ các luồng Java tới các phần tử pthread (tức là chi phí đầu vào Java nio lớn hơn chi phí chuyển ngữ cảnh).

Nhưng bây giờ tôi thấy tất cả các máy chủ "cắt cạnh" sử dụng thư viện không đồng bộ (Java nio, epoll, thậm chí node.js). Điều này có nghĩa là async đã thắng?

Answer 1

Không theo ý kiến ​​của tôi. Nếu cả hai mô hình đều được triển khai tốt (đây là yêu cầu lớn), tôi nghĩ rằng khái niệm về NIO nên chiếm ưu thế.

Tại trung tâm của máy tính là lõi. Không có vấn đề gì bạn làm, bạn không thể song song ứng dụng của bạn nhiều hơn bạn có lõi. tức là nếu bạn có một máy tính 4 lõi, bạn chỉ có thể làm 4 việc cùng một lúc (tôi đang chú ý đến một số chi tiết ở đây, nhưng điều đó đủ cho đối số này).

Mở rộng suy nghĩ đó, nếu bạn có nhiều chủ đề hơn lõi, bạn sẽ lãng phí. Chất thải đó có hai dạng. Đầu tiên là chi phí của các chủ đề phụ. Thứ hai là thời gian chuyển đổi giữa các luồng. Cả hai đều có thể nhỏ, nhưng họ đang có.

Lý tưởng nhất là bạn có một chuỗi trên mỗi lõi và mỗi luồng trong số đó đang chạy ở tốc độ xử lý 100% trên lõi của chúng. Chuyển đổi tác vụ sẽ không xảy ra trong lý tưởng. Tất nhiên có hệ điều hành, nhưng nếu bạn lấy một máy tính cốt lõi 16 và để lại 2-3 chủ đề cho hệ điều hành, sau đó 13-14 còn lại đi về phía ứng dụng của bạn. Những chủ đề đó có thể chuyển đổi những gì họ đang thực hiện trong phạm vi ứng dụng của bạn, như khi chúng bị chặn bởi yêu cầu IO, nhưng không phải trả chi phí đó ở cấp hệ điều hành. Viết nó ngay vào ứng dụng của bạn.

Một ví dụ tuyệt vời về việc chia tỷ lệ này được hiển thị trong SEDA http://www.eecs.harvard.edu/~mdw/proj/seda/. Nó cho thấy khả năng mở rộng quy mô tốt hơn nhiều theo tải so với mô hình chuỗi yêu cầu theo yêu cầu.

Trải nghiệm cá nhân của tôi là với Netty. Tôi đã có một ứng dụng đơn giản. Tôi đã triển khai tốt trong cả Tomcat và Netty. Sau đó, tôi tải thử nghiệm nó với 100 yêu cầu đồng thời (lên tới 800 tôi tin). Cuối cùng Tomcat chậm lại để thu thập dữ liệu và thể hiện hành vi cực kỳ bùng nổ/chậm chạp. Trong khi thực hiện Netty chỉ đơn giản là tăng thời gian đáp ứng, nhưng tiếp tục với thông lượng tổng thể cực kỳ.

Xin lưu ý, bản lề này được thực hiện vững chắc. NIO vẫn còn tốt hơn với thời gian. Chúng tôi đang tìm hiểu cách điều chỉnh các hệ điều hành máy chủ để làm việc tốt hơn với nó cũng như cách triển khai các JVM để tận dụng tốt hơn chức năng của hệ điều hành. Tôi không nghĩ rằng một người chiến thắng có thể được tuyên bố, nhưng tôi tin rằng NIO sẽ là người chiến thắng cuối cùng, và nó đã làm khá tốt rồi.

Answer 2

Nó nhanh hơn miễn là có đủ bộ nhớ.

Khi có quá nhiều kết nối, hầu hết trong số đó là không hoạt động, NIO có thể lưu chủ đề do đó tiết kiệm bộ nhớ và hệ thống có thể xử lý nhiều người dùng hơn mô hình chuỗi kết nối.

CPU không phải là nhân tố trực tiếp tại đây. Với NIO, bạn thực sự cần phải tự mình triển khai một mô hình luồng, vốn không thể nhanh hơn các luồng của JVM.

Trong cả hai lựa chọn, bộ nhớ là nút cổ chai cuối cùng. Khi tải tăng và bộ nhớ sử dụng các phương pháp tiếp cận tối đa, GC sẽ rất bận rộn, và hệ thống thường thể hiện các triệu chứng của CPU 100%.

Answer 3

Một số thời gian trước, tôi đã tìm thấy rather interesting presentation cung cấp một số thông tin chi tiết về "lý do mô hình luồng trên mỗi khách hàng cũ tốt hơn". Thậm chí còn có số đo. Tuy nhiên tôi vẫn nghĩ về nó. Theo tôi, câu trả lời hay nhất cho câu hỏi này là "nó phụ thuộc" bởi vì hầu hết (nếu không phải tất cả) các quyết định kỹ thuật đều là các lệnh giao dịch.

Answer 4

Giống như bản trình bày đó đã nói - có tốc độ và có khả năng mở rộng.

Một trường hợp trong đó chuỗi yêu cầu gần như chắc chắn sẽ nhanh hơn bất kỳ giải pháp không đồng bộ nào là khi bạn có số lượng khách hàng tương đối nhỏ (ví dụ: < 100), nhưng mỗi khách hàng có khối lượng rất cao. ví dụ. một ứng dụng thời gian thực mà không có hơn 100 khách hàng đang gửi/tạo 500 tin nhắn mỗi giây. Mô hình đề xuất cho mỗi yêu cầu chắc chắn sẽ hiệu quả hơn bất kỳ giải pháp vòng lặp sự kiện async nào. Async cân bằng tốt hơn khi có nhiều yêu cầu/khách hàng bởi vì nó không lãng phí các chu kỳ chờ đợi trên nhiều kết nối máy khách, nhưng khi bạn có một số lượng lớn các máy khách có ít chờ đợi, nó kém hiệu quả hơn. Từ những gì tôi thấy, các tác giả của Node và Netty đều nhận ra rằng những khung công tác này chủ yếu nhằm giải quyết các tình huống khả năng mở rộng kết nối với khối lượng lớn, thay vì nhanh hơn cho một số lượng nhỏ các máy khách có khối lượng lớn hơn.