Vấn đề hiệu suất Socket Java TCP/IP

Question

Ứng dụng của chúng tôi đang đọc dữ liệu rất nhanh qua các cổng TCP/IP trong Java. Chúng tôi đang sử dụng thư viện NIO với một Ổ cắm không chặn và Bộ chọn để cho biết sự sẵn sàng để đọc. Trung bình, thời gian xử lý tổng thể để đọc và xử lý dữ liệu đọc là dưới một phần nghìn giây. Tuy nhiên, chúng tôi thường xuyên thấy các gai 10-20 mili giây. (chạy trên Linux).

Sử dụng tcpdump chúng tôi có thể thấy sự khác biệt về thời gian giữa việc đọc tcpdump của 2 thông điệp kín đáo và so sánh điều đó với thời gian đăng ký của chúng tôi. Chúng tôi thấy tcpdump dường như không có độ trễ, trong khi ứng dụng có thể hiển thị 20 mili giây. Chúng tôi khá chắc chắn đây không phải GC, vì nhật ký GC cho thấy hầu như không có GC đầy đủ, và trong JDK 6 (từ những gì tôi hiểu), GC mặc định là song song, vì vậy nó không nên tạm dừng các luồng ứng dụng (trừ khi làm đầy đủ GC). Có vẻ như có sự chậm trễ cho phương pháp Selector.select(0) của Java để trả lại sự sẵn sàng để đọc, bởi vì ở lớp TCP, dữ liệu đã sẵn sàng để đọc (và tcpdump đang đọc nó).

Thông tin bổ sung: tại tải cao điểm, chúng tôi xử lý khoảng 6.000 x 150 byte trung bình cho mỗi thư hoặc khoảng 900 MB mỗi giây.

Answer 1

Bộ sưu tập eden vẫn phải tạm dừng STW để 20ms có thể hoàn toàn bình thường tùy thuộc vào hành vi phân bổ & kích thước/kích thước heap của tập hợp trực tiếp.

Answer 2

Mã Java của bạn có đang chạy dưới RTLinux hay một số bản phân phối khác với khả năng lập lịch thời gian thực cứng không? Nếu không, 10-20 msec của jitter trong thời gian xử lý có vẻ hoàn toàn hợp lý, và mong đợi.

Answer 3

Từ tcpdump faq:

KHI là một gói thời gian đóng dấu? LÀM THẾ NÀO CHÍNH XÁC LÀ TEM THỜI GIAN?

Trong hầu hết các hệ điều hành trên đó tcpdump và libpcap chạy, các gói dữ liệu là thời gian đóng dấu như là một phần của quá trình điều khiển thiết bị giao diện mạng, hoặc ngăn xếp mạng, xử lý nó. Điều này có nghĩa là gói không phải là thời gian đóng dấu ngay khi nó đến tại giao diện mạng; sau khi gói đến tại giao diện mạng , sẽ có một sự chậm trễ cho đến khi một ngắt được giao hoặc giao diện mạng được thăm dò (ví dụ, giao diện mạng có thể không làm gián đoạn dẫn chương trình ngay lập tức - người lái xe có thể được thiết lập lên để thăm dò giao diện nếu số lượng lưu lượng truy cập mạng là , để giảm số số lần ngắt và xử lý nhiều gói hơn cho mỗi gián đoạn), và sẽ bị trì hoãn thêm tại số tại thời điểm bắt đầu ngắt và xử lý dấu thời gian là được tạo.

Vì vậy, tỷ lệ là dấu thời gian được tạo trong lớp nhân đặc quyền và 20ms bị mất là chuyển ngữ cảnh trở lại không gian người dùng và sang Java và logic bộ chọn mạng JVM. Nếu không có phân tích nhiều hơn về hệ thống như một toàn thể tôi không nghĩ rằng nó có thể làm cho một lựa chọn khẳng định nguyên nhân.

Answer 4

Tôi gặp sự cố tương tự trong dịch vụ java mà tôi đang thực hiện. Khi gửi cùng một yêu cầu liên tục từ máy khách, máy chủ sẽ chặn tại cùng một vị trí trong luồng trong 25-35ms. Tắt thuật toán của Nagle trong ổ cắm đã sửa lỗi này cho tôi. Điều này có thể được thực hiện bằng cách gọi setTcpNoDelay (true) trên Socket. Điều này có thể dẫn đến sự tắc nghẽn mạng gia tăng vì ACK giờ đây sẽ được gửi riêng biệt như gói. Xem http://en.wikipedia.org/wiki/Nagle%27s_algorithm để biết thêm thông tin về thuật toán của Nagle.