IPC performance Named Pipe vs Socket

Question

Everyone seems to say named pipes are faster than sockets IPC  How much faster are they  I would prefer to use sockets because they can do two-way communication and are very flexible but will choose speed over flexibility if it is by considerable amount

User · Answer

You can use lightweight solution like ZeroMQ   zmq 0mq    It is very easy to use and dramatically faster then sockets

User · Answer

I m going to agree with shodanex  it looks like you re prematurely trying to optimize something that isn t yet problematic  Unless you know sockets are going to be a bottleneck  I d just use them   A lot of people who swear by named pipes find a little savings  depending on how well everything else is written   but end up with code that spends more time blocking for an IPC reply than it does doing useful work  Sure  non-blocking schemes help this  but those can be tricky  Spending years bringing old code into the modern age  I can say  the speedup is almost nil in the majority of cases I ve seen   If you really think that sockets are going to slow you down  then go out of the gate using shared memory with careful attention to how you use locks  Again  in all actuality  you might find a small speedup  but notice that you re wasting a portion of it waiting on mutual exclusion locks  I m not going to advocate a trip to futex hell  well  not quite hell anymore in 2015  depending upon your experience    Pound for pound  sockets are  almost  always the best way to go for user space IPC under a monolithic kernel    and  usually  the easiest to debug and maintain

User · Answer

I would suggest you take the easy path first  carefully isolating the IPC mechanism so that you can change from socket to pipe  but I would definitely go with socket first  You should be sure IPC performance is a problem before preemptively optimizing   And if you get in trouble because of IPC speed  I think you should consider switching to shared memory rather than going to pipe   If you want to do some transfer speed testing  you should try socat  which is a very versatile program that allows you to create almost any kind of tunnel

User · Answer

As often  numbers says more than feeling  here are some data  Pipe vs Unix Socket Performance  opendmx net    This benchmark shows a difference of about 12 to 15  faster speed for pipes

User · Answer

For two way communication with named pipes     If you have few processes  you can open two pipes for two directions  processA2ProcessB and processB2ProcessA  If you have many processes  you can open in and out pipes for every process  processAin  processAout  processBin  processBout  processCin  processCout etc  Or you can go hybrid as always      Named pipes are quite easy to implement    E g  I implemented a project in C with named pipes  thanks to standart file input-output based communication  fopen  fprintf  fscanf      it was so easy and clean  if that is also a consideration    I even coded them with java  I was serializing and sending objects over them    Named pipes has one disadvantage    they do not scale on multiple computers like sockets since they rely on filesystem  assuming shared filesystem is not an option

User · Answer

Keep in mind that sockets does not necessarily mean IP  and TCP or UDP   You can also use UNIX sockets  PF UNIX   which offer a noticeable performance improvement over connecting to 127 0 0 1

User · Answer

Best results you ll get with Shared Memory solution    Named pipes are only 16  better than TCP sockets   Results are get with IPC benchmarking    System  Linux  Linux ubuntu 4 4 0 x86 64 i7-6700K 4 00GHz  Message  128 bytes  Messages count  1000000   Pipe benchmark   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   FIFOs  named pipes  benchmark   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   Message Queue benchmark   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   Shared Memory benchmark   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   TCP sockets benchmark   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   Unix domain sockets benchmark   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   ZeroMQ benchmark   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

User · Answer

One problem with sockets is that they do not have a way to flush the buffer  There is something called the Nagle algorithm which collects all data and flushes it after 40ms  So if it is responsiveness and not bandwidth you might be better off with a pipe    You can disable the Nagle with the socket option TCP NODELAY but then the reading end will never receive two short messages in one single read call   So test it  i ended up with none of this and implemented memory mapped based queues with pthread mutex and semaphore in shared memory  avoiding a lot of kernel system calls  but today they aren t very slow anymore

User · Answer

Named pipes and sockets are not functionally equivalent  sockets provide more features  they are bidirectional  for a start    We cannot tell you which will perform  better  but I strongly suspect it doesn t matter   Unix domain sockets will do pretty much what tcp sockets will  but only on the local machine and with  perhaps a bit  lower overhead   If a Unix socket isn t fast enough and you re transferring a lot of data  consider using shared memory between your client and server  which is a LOT more complicated to set up    Unix and NT both have  Named pipes  but they are totally different in feature set

User · Answer

If you do not need speed  sockets are the easiest way to go    If what you are looking at is speed  the fastest solution is shared Memory  not named pipes

[linux] IPC performance: Named Pipe vs Socket

Examples related to linux

Examples related to performance

Examples related to sockets

Examples related to ipc

Examples related to named-pipes