Cài đặt thích hợp cho ZMQ khi gửi tin nhắn 500K 64 byte là gì?

Question

Tôi có một ứng dụng định kỳ cần gửi một bản chụp trạng thái hiện tại của nó, hiện tại sẽ được đại diện bởi khoảng 500.000 tin nhắn 64 byte. Tôi đã gặp khó khăn khi nhận được nhiều thư này được gửi và nhận nhanh chóng và đáng tin cậy khi sử dụng ZMQ.

Tôi đã sử dụng PUB/SUB trên tcp để thực hiện việc này, nhưng tôi không kết hợp với mẫu hoặc giao thức miễn là nó sẽ hoàn thành công việc. Trong các thí nghiệm của tôi, tôi tập trung vào việc gửi và nhận dấu nước cao, gửi và nhận các cài đặt bộ đệm, và thêm một số giấc ngủ vào vòng lặp gửi để cố gắng làm chậm nó xuống một chút. Với các thiết lập có vẻ khá hào phóng với tôi (500K HWM, bộ đệm 10MB) và chỉ sử dụng kết nối loopback, các tin nhắn vẫn chưa được nhận một cách nhất quán.

Tôi quan tâm đến cài đặt thích hợp cho các thông số này hoặc các thông số điều chỉnh khác, và rộng hơn về cách lý do về hiệu ứng mà các cài đặt khác nhau sẽ có.

Một số thông tin chi tiết có thể giúp cung cấp một câu trả lời thích hợp:

• Sự phân bố là một đến nhiều. Số người nhận dự kiến ​​là khoảng 20.

• Mỗi thông báo đại diện cho tập hợp thông tin về một công cụ tài chính khác nhau, tất cả đều được quan sát cùng một lúc. Trong các lý lẽ tâm trí của tôi có thể được thực hiện cho cả hai kết hợp chúng thành một thông điệp lớn (tập hợp tất cả các thông điệp một cách hợp lý tạo nên một ảnh chụp hoàn chỉnh) và để giữ chúng riêng biệt (khách hàng có thể chỉ quan tâm đến một số công cụ và tôi nghĩ điều này sẽ giúp ích cho bạn) lọc chúng ra dễ dàng hơn).

• Tần suất dự kiến ​​của thư về cơ bản không nhanh hơn 20 mili giây và không chậm hơn 5 giây. Nơi tôi thực sự đất có thể sẽ bị ảnh hưởng bởi cân nhắc hiệu suất (tức là, máy chủ của tôi có thể thực sự bơm các thông điệp ra sao và tốc độ dữ liệu nào sẽ chứng minh áp đảo cho khách hàng).

Answer 1

Sau một ngày thử nghiệm bán ngẫu nhiên với kết hợp khác nhau, tôi đã đến kết luận dự kiến ​​như sau:

• Thêm báo cáo ngủ trong vòng gửi tôi để hạn chế tỷ lệ nhắn cải thiện độ tin cậy về cơ bản bất kỳ tập hợp các tùy chọn nào.

• Gửi 500.000 thư dưới dạng khung của một thư thay vì 500K thư cá nhân cải thiện độ tin cậy.

• Sử dụng giao thức epgm thay vì giao thức tcp cho phép đạt được thông lượng cao hơn.

• Với tùy chọn epgm, tốc độ đa hướng cần phải khớp với tốc độ tin nhắn mong muốn đạt được bằng các câu lệnh ngủ.

• Tăng dấu nước cao và bộ đệm giúp tăng độ tin cậy, nhưng bạn phải tăng cả cài đặt và thực hiện cả trên máy khách và máy chủ. Nếu tất cả không được thực hiện kết hợp nó có xu hướng không giúp đỡ. Bạn phải thiết lập những điều này khá cao để có được bất kỳ loại độ tin cậy nào đang chạy với các thông báo riêng lẻ (trái ngược với các khung của một thông điệp). Trong trường hợp này, tôi đã không nhận được kết quả tốt cho đến khi tôi có các điểm đánh dấu nước cao được đặt là 1.000.000 và bộ đệm được đặt thành 65 MB. (Hai lần kích thước của tập hợp các tin nhắn tôi đã cố gửi đi.) Điều này cao hơn rất nhiều so với bản năng tôi nghĩ để thử.Trường hợp đó đã tạm dừng 5 giây giữa mỗi vòng 500 nghìn tin nhắn. Đưa khoảng thời gian xuống 1 giây, tôi phải đẩy chúng lên cao hơn, gấp 4 lần kích thước của một loạt tin nhắn.

• Với epgm, cài đặt khoảng thời gian khôi phục không giúp được nhiều.

Answer 2

Hãy chia nhỏ điều này.

Thứ nhất, tại sao HWM không phải là "làm việc":

Các HWM không phải là một giới hạn chính xác, kể từ bộ đệm bên trong được làm đầy và làm trống bởi hai luồng riêng biệt, và số lượng của không gian có sẵn có thể tụt hậu khá rất nhiều khi có nhiều hoạt động. Trang người dùng zmq_setsockopt 0MQ cho biết, "0MQ không đảm bảo rằng socket sẽ chấp nhận nhiều thông báo ZMQ_SNDHWM và giới hạn thực tế có thể thấp hơn 60-70% tùy thuộc vào luồng thông báo trên ổ cắm".

Thứ hai, tại sao bạn mất thông điệp:

Như bạn đổ điệp 0,5m (x 20) vào bộ đệm của ổ cắm, bạn sẽ ngẫu nhiên nhấn HWM và hành vi socket PUB của sau đó là để thả các thông điệp mà nó không thể xếp hàng.

Thứ ba, cách giải quyết vấn đề này:

Không có lý do gì để chia tiểu bang thành các thư riêng biệt; lý do duy nhất cho điều này sẽ là nếu nhà nước không phù hợp với trí nhớ, mà nó dễ dàng. Gửi dưới dạng nhiều phần (ZMQ_SNDMORE); điều này tạo ra một thông điệp hiệu quả duy nhất có 1 vị trí trong bộ đệm gửi đi.

Sau đó, hãy xóa giới hạn 500 nghìn HWM của bạn và hoàn nguyên về giá trị mặc định (1000) sẽ đầy đủ.

Thứ tư, làm thế nào để có được hiệu suất tốt hơn:

Rõ ràng, hồ sơ và cải thiện xuất bản của bạn và mã số thuê bao càng tốt; đây là những tắc nghẽn thông thường.

Sau đó, hãy xem xét một số hình thức nén trên thư nếu nó thưa thớt và bạn có thể làm điều đó mà không tốn quá nhiều chi phí CPU. Tại 20 thuê bao, bạn thường sẽ thu được nhiều hơn từ chi phí mạng hơn bạn sẽ bị mất từ ​​chi phí CPU.

Cuối cùng, nếu bạn phát triển đến nhiều người đăng ký hơn và đó là một hệ thống quan trọng, hãy xem PGM phát đa hướng, điều này sẽ loại bỏ hiệu quả chi phí mạng.