3 ms·

So, what method do you propose for communicating locally which will be faster than the network ? Unix sockets ? Pipes ?

• easytiger 4y ago
  > Unix sockets ? Pipes ? It has been many years since i tested this but unix sockets seemed slower to me than loopback TCP even If you need real speed you should use UDP/MC, or I have used a lot of commercial middlewares which used "shared memory" transports. i.e. messaging paradigm APIs wrapping various configurable messaging middlewares to provide a fairly unified interface to the application messaging concepts.
  • chmod775 4y ago
    >It has been many years since i tested this but unix sockets seemed slower to me than loopback TCP even They're essentially the same... except they're not and there's a boatload of work in the middle that doesn't need to be done for unix domain sockets. I can imagine some edge-cases however, where differences in stacks and configuration (in/out buffers vs. shared buffers, buffer sizes, packet loss vs. reliable, locking, blocking vs. non-blocking writes) may lead to more optimal scheduling under concurrent workloads. As soon as you have more than one thread doing something, there's a boatload of moving parts to consider. But if you have everything properly tuned, unix domain sockets should win every time. If your results said something else, you probably weren't benchmarking what you thought you were benchmarking.
• scott_s 4y ago
  Shared memory of some kind will be fastest. It requires a re-architecture of the application, some of the times. Unfortunately, I can't find the Linux kernel mailing list response any more, but the kernel devs were not sympathetic to the use case of processes communicating over TCP on the same host.