Hiệu suất IPC: Ống đặt tên so với Ổ cắm

Mọi người dường như nói rằng đường ống được đặt tên nhanh hơn so với ổ cắm IPC. Chúng nhanh hơn bao nhiêu? Tôi thích sử dụng các ổ cắm hơn vì chúng có thể thực hiện giao tiếp hai chiều và rất linh hoạt nhưng sẽ chọn tốc độ thay vì tính linh hoạt nếu nó ở mức đáng kể.

Tôi khuyên bạn nên đi theo con đường dễ dàng trước tiên, cẩn thận cô lập cơ chế IPC để bạn có thể thay đổi từ ổ cắm sang đường ống, nhưng tôi chắc chắn sẽ đi với ổ cắm trước. Bạn nên chắc chắn rằng hiệu suất IPC là một vấn đề trước khi tối ưu hóa trước.

Và nếu bạn gặp rắc rối vì tốc độ IPC, tôi nghĩ bạn nên cân nhắc chuyển sang bộ nhớ chia sẻ hơn là chuyển sang đường ống.

Nếu bạn muốn thực hiện một số kiểm tra tốc độ truyền, bạn nên thử socat , đây là một chương trình rất linh hoạt cho phép bạn tạo hầu hết mọi loại đường hầm.

Kết quả tốt nhất bạn sẽ nhận được với giải pháp Bộ nhớ dùng chung .

Các đường ống được đặt tên chỉ tốt hơn 16% so với các ổ cắm TCP .

Kết quả nhận được với điểm chuẩn IPC :

• Hệ thống: Linux (Linux ubuntu 4.4.0 x86_64 i7-6700K 4.00GHz)
• Tin nhắn: 128 byte
• Số lượng tin nhắn: 1000000

Tiêu chuẩn đường ống:

Message size:       128
Message count:      1000000
Total duration:     27367.454 ms
Average duration:   27.319 us
Minimum duration:   5.888 us
Maximum duration:   15763.712 us
Standard deviation: 26.664 us
Message rate:       36539 msg/s

Tiêu chuẩn FIFOs (đường ống được đặt tên):

Message size:       128
Message count:      1000000
Total duration:     38100.093 ms
Average duration:   38.025 us
Minimum duration:   6.656 us
Maximum duration:   27415.040 us
Standard deviation: 91.614 us
Message rate:       26246 msg/s

Tiêu chuẩn hàng đợi tin nhắn:

Message size:       128
Message count:      1000000
Total duration:     14723.159 ms
Average duration:   14.675 us
Minimum duration:   3.840 us
Maximum duration:   17437.184 us
Standard deviation: 53.615 us
Message rate:       67920 msg/s

Chuẩn bộ nhớ dùng chung:

Message size:       128
Message count:      1000000
Total duration:     261.650 ms
Average duration:   0.238 us
Minimum duration:   0.000 us
Maximum duration:   10092.032 us
Standard deviation: 22.095 us
Message rate:       3821893 msg/s

Điểm chuẩn của ổ cắm TCP:

Message size:       128
Message count:      1000000
Total duration:     44477.257 ms
Average duration:   44.391 us
Minimum duration:   11.520 us
Maximum duration:   15863.296 us
Standard deviation: 44.905 us
Message rate:       22483 msg/s

Điểm chuẩn ổ cắm tên miền Unix:

Message size:       128
Message count:      1000000
Total duration:     24579.846 ms
Average duration:   24.531 us
Minimum duration:   2.560 us
Maximum duration:   15932.928 us
Standard deviation: 37.854 us
Message rate:       40683 msg/s

Điểm chuẩn ZeroMQ:

Message size:       128
Message count:      1000000
Total duration:     64872.327 ms
Average duration:   64.808 us
Minimum duration:   23.552 us
Maximum duration:   16443.392 us
Standard deviation: 133.483 us
Message rate:       15414 msg/s

Tôi sẽ đồng ý với shodanex, có vẻ như bạn đã sớm cố gắng tối ưu hóa một thứ gì đó chưa có vấn đề. Trừ khi bạn biết các ổ cắm sẽ là một nút cổ chai, tôi chỉ sử dụng chúng.

Rất nhiều người sử dụng các đường ống được đặt tên sẽ tiết kiệm được một chút (tùy thuộc vào cách mọi thứ khác được viết tốt như thế nào), nhưng cuối cùng mã dành nhiều thời gian chặn cho một phản hồi IPC hơn là nó thực hiện công việc hữu ích. Chắc chắn, các kế hoạch không chặn sẽ giúp được điều này, nhưng những kế hoạch đó có thể phức tạp. Tôi có thể nói, dành nhiều năm để đưa mã cũ vào thời đại hiện đại, tốc độ tăng gần như bằng không trong phần lớn các trường hợp tôi đã thấy.

Nếu bạn thực sự nghĩ rằng ổ cắm sẽ làm bạn chậm lại, thì hãy ra khỏi cổng bằng cách sử dụng bộ nhớ dùng chung và chú ý cẩn thận đến cách bạn sử dụng ổ khóa. Một lần nữa, trên thực tế, bạn có thể thấy một tốc độ tăng nhỏ, nhưng lưu ý rằng bạn đang lãng phí một phần của nó khi chờ đợi các khóa loại trừ lẫn nhau. Tôi sẽ không ủng hộ một chuyến đi đến địa ngục futex (tốt, không hẳn địa ngục nữa vào năm 2015, tùy thuộc vào kinh nghiệm của bạn).

Pound cho pound, socket là (hầu như) luôn là cách tốt nhất để sử dụng IPC không gian người dùng dưới một nhân nguyên khối .. và (thường) là cách dễ nhất để gỡ lỗi và bảo trì.

Hãy nhớ rằng các socket không nhất thiết có nghĩa là IP (và TCP hoặc UDP). Bạn cũng có thể sử dụng ổ cắm UNIX (PF_UNIX), cung cấp cải tiến hiệu suất đáng chú ý so với kết nối với 127.0.0.1

Thông thường, các con số nói lên nhiều điều hơn là cảm giác, đây là một số dữ liệu: Hiệu suất Pipe so với Unix Socket (opendmx.net) .

Điểm chuẩn này cho thấy sự khác biệt về tốc độ nhanh hơn khoảng 12 đến 15% đối với đường ống.

Nếu bạn không cần tốc độ, ổ cắm là cách dễ nhất để sử dụng!

Nếu những gì bạn đang xem xét là tốc độ, giải pháp nhanh nhất là Bộ nhớ chia sẻ, không phải đường ống được đặt tên.

Đối với giao tiếp hai chiều với các đường ống được đặt tên:

• Nếu bạn có ít quy trình, bạn có thể mở hai đường ống theo hai hướng (processA2ProcessB và processB2ProcessA)
• Nếu bạn có nhiều quy trình, bạn có thể mở các đường dẫn vào và ra cho mọi quy trình (processAin, processAout, processBin, processBout, processCin, processCout, v.v.)
• Hoặc bạn có thể lai như mọi khi :)

Đường ống được đặt tên khá dễ thực hiện.

Ví dụ: tôi đã thực hiện một dự án trong C với các đường ống được đặt tên, nhờ giao tiếp dựa trên đầu vào-đầu ra của tệp standart (fopen, fprintf, fscanf ...) nó rất dễ dàng và sạch sẽ (nếu đó cũng là một vấn đề cần xem xét).

Tôi thậm chí còn mã hóa chúng bằng java (Tôi đã tuần tự hóa và gửi các đối tượng qua chúng!)

Đường ống được đặt tên có một nhược điểm:

• chúng không mở rộng quy mô trên nhiều máy tính như ổ cắm vì chúng dựa vào hệ thống tệp (giả sử hệ thống tệp được chia sẻ không phải là một tùy chọn)

Một vấn đề với các ổ cắm là chúng không có cách làm sạch bộ đệm. Có một thứ được gọi là thuật toán Nagle thu thập tất cả dữ liệu và xóa nó sau 40ms. Vì vậy, nếu đó là khả năng đáp ứng chứ không phải băng thông, bạn có thể tốt hơn với một đường ống.

Bạn có thể vô hiệu hóa Nagle với tùy chọn socket TCP_NODELAY nhưng khi đó phần cuối đọc sẽ không bao giờ nhận được hai tin nhắn ngắn trong một cuộc gọi đã đọc.

Vì vậy, hãy kiểm tra nó, tôi đã kết thúc với điều này và thực hiện các hàng đợi dựa trên ánh xạ bộ nhớ với pthread mutex và semaphore trong bộ nhớ chia sẻ, tránh được rất nhiều lệnh gọi hệ thống hạt nhân (nhưng ngày nay chúng không còn chậm nữa).

Các đường ống và ổ cắm được đặt tên không tương đương về mặt chức năng; ổ cắm cung cấp nhiều tính năng hơn (chúng là hai chiều, để bắt đầu).

Chúng tôi không thể cho bạn biết cái nào sẽ hoạt động tốt hơn, nhưng tôi thực sự nghi ngờ điều đó không quan trọng.

Các ổ cắm miền Unix sẽ làm được khá nhiều điều mà các ổ cắm tcp sẽ làm, nhưng chỉ trên máy cục bộ và với chi phí thấp hơn (có lẽ một chút).

Nếu ổ cắm Unix không đủ nhanh và bạn đang truyền nhiều dữ liệu, hãy cân nhắc sử dụng bộ nhớ dùng chung giữa máy khách và máy chủ của bạn (phức tạp hơn rất nhiều để thiết lập).

Unix và NT đều có "Đường ống được đặt tên" nhưng chúng hoàn toàn khác nhau về bộ tính năng.

Bạn có thể sử dụng giải pháp nhẹ như ZeroMQ [ zmq / 0mq ]. Nó rất dễ sử dụng và nhanh hơn đáng kể so với ổ cắm.