Java I/O so với Java I/O mới (NIO) với Linux NPTL

Question

Máy chủ web của tôi sử dụng Java I/O thông thường với chuỗi cho mỗi cơ chế kết nối. Ngày nay, họ đang nhận được trên đầu gối của họ với người dùng tăng lên (kết nối bỏ phiếu dài). Tuy nhiên, các kết nối chủ yếu là nhàn rỗi. Trong khi điều này có thể được giải quyết bằng cách thêm nhiều máy chủ web, tôi đã cố gắng thực hiện một số nghiên cứu về triển khai NIO.

Tôi đã có một ấn tượng hỗn hợp về nó. Tôi đã đọc về các điểm chuẩn trong đó I/O thông thường với thư viện NPTL mới trong Linux hoạt động tốt hơn NIO.

Trải nghiệm thực tế về cấu hình và sử dụng NPTL mới nhất cho Linux với Java I/O là gì? Có hiệu suất tăng nào không?

Và trên một phạm vi câu hỏi lớn hơn:

số lượng tối đa/O và ngăn chặn chủ đề I (mà chúng ta cấu hình trong hồ bơi Tomcat thread) trong một máy lớp máy chủ tiêu chuẩn là gì (Dell với một bộ vi xử lý quad-core), chúng tôi hy vọng sẽ thực hiện bình thường (với thư viện Linux NPTL?). Tác động gì nếu threadpool được thực sự lớn, nói hơn 1000 chủ đề?

Mọi tham chiếu và con trỏ sẽ được đánh giá rất nhiều.

Answer 1

khêu gợi trên blog đăng tải, (2008) blog tuyên bố "Avoid NIO, get better throughput." Paul Tyma của ~ 5000 bài mà không cần bất kỳ sự cố; folks Tôi đã nghe tuyên bố hơn:

1. Với NPTL trên, Sun và Blackwidow JVM 1.4.2 quy mô một cách dễ dàng để 5000+ đề. Mô hình chặn là nhanh hơn 25-35% so với sử dụng bộ chọn NIO. Rất nhiều kỹ thuật được đề xuất bởi các thành viên EmberIO được sử dụng - sử dụng nhiều bộ chọn, thực hiện nhiều (2) lần đọc nếu số đầu tiên được trả về tương đương EAGAIN trong Java. Tuy nhiên, chúng tôi không thể đánh bại chủ đề đồng bằng cho mỗi mô hình kết nối với Linux NPTL.

Tôi nghĩ rằng chính ở đây là để measure the overhead and performance, và làm cho chuyển sang non-blocking I/O chỉ khi bạn biết bạn cần phải và có thể chứng minh một sự cải tiến. Nỗ lực bổ sung để viết và duy trì mã không bị chặn phải được đưa vào quyết định của bạn. Đơn hàng của tôi là, nếu ứng dụng của bạn có thể được thể hiện rõ ràng bằng cách sử dụng I/O đồng bộ/chặn, DO THAT. Nếu ứng dụng của bạn tuân theo I/O không chặn và bạn sẽ không chỉ phát minh lại việc chặn I/O nặng trong không gian ứng dụng, CONSIDER chuyển sang nio dựa trên nhu cầu hiệu suất được đo. Tôi ngạc nhiên khi tôi poke xung quanh kết quả google cho điều này như thế nào vài trong số các nguồn tài nguyên thực sự trích dẫn bất kỳ (gần đây) số!

Ngoài ra, hãy xem Paul Tyma's presentation slides: Cách cũ là mới một lần nữa. Dựa trên công việc của mình tại Google, các con số cụ thể cho thấy rằng I/O luồng đồng bộ là khá khả năng mở rộng trên Linux, và xem xét "NIO nhanh hơn" một huyền thoại đã đúng trong một thời gian, nhưng không còn nữa. Một số bình luận bổ sung tốt here on Comet Daily. Ông trích dẫn như sau (giai thoại, vẫn không có liên kết vững chắc để chuẩn, vv ...) cho kết quả trên NPTL:

Trong các thử nghiệm, NPTL thành công trong việc bắt đầu 100.000 đề trên IA-32 trong hai giây. Trong khi đó, thử nghiệm này dưới một hạt nhân mà không NPTL sẽ lấy khoảng 15 phút

Nếu bạn thực sự đang chạy vào vấn đề khả năng mở rộng, bạn có thể muốn sử dụng tune the thread stack sizeXX:ThreadStackSize. Vì bạn đề cập đến Tomcat see here.

Cuối cùng, nếu bạn bị ràng buộc và quyết tâm sử dụng I/O không chặn, hãy cố gắng xây dựng trên existing framework by people who know what they're doing. Tôi đã lãng phí quá nhiều thời gian của riêng tôi cố gắng để có được một giải pháp I/O phức tạp không bị chặn đúng (vì những lý do sai).

Xem thêm related on SO.

Answer 2

Các liên kết bạn có thể tìm thấy hữu ích:

• Handling of 100.000+ open connections
• The C10K problem
• Scalable Network Programming

Bạn cũng có thể có một cái nhìn tại http://nodejs.org/ mà không phải là một JVM-công nghệ, nhưng một cách hoàn hảo xử lý hàng nghìn kết nối (và, nếu tôi không nhầm, hãy sử dụng NPTL đằng sau hậu trường)

Một số tốt khuôn khổ đã được chứng minh nio web dưới JVM:

• Project Grizzly (Glassfish subproject)
• Netty
• Apache MINA

Answer 3

Tôi mong đợi bất kỳ máy chủ nào có đủ bộ nhớ để xử lý hàng chục nghìn luồng nhàn rỗi dễ dàng, có thể là hàng trăm nghìn.

Answer 4

Sajid, tôi thấy rằng bạn đang thực hiện Comet (long polling).

Hầu như không ai nói về vấn đề thực thi mã người dùng cho các sự kiện Comet trong NIO. Chủ đề NIO gửi các sự kiện Comet gọi mã của bạn, nếu mã của bạn không đủ tốt, bạn đang chặn luồng quan trọng này và các kết nối Comet khác phải WAIT vì luồng NIO đang thực hiện một công việc tương tự với trình lập lịch trình của SO.Đây không phải là vấn đề trong Comet với IO vì thread chỉ dành cho sự kiện/nhiệm vụ Comet của bạn và trình lên lịch có thể từ bỏ chuỗi của bạn khi nó muốn (không dễ dàng như vậy với cách tiếp cận NIO).

Vấn đề duy nhất tôi thấy với "Comet đồng bộ" (IO dựa) là mức tiêu thụ bộ nhớ của ngăn xếp luồng.