Reducing network latency in communication of high volume intranet applications

We have a set of server applications which receive measurement data from equipment/tools. Message transfer time is currently our main bottleneck, so we are interested in red开发者_Python百科ucing it to improve the process. The communication between the tools and server applications is via TCP/IP sockets made using C++ on Redhat Linux.

Is it possible to reduce the message transfer time using hardware, by changing the TCP/IP configuration settings or by tweaking tcp kernel functions? (we can sacrifice security for speed, since communication is on a secure intranet)

---

Depending on the workload, disabling Nagle's Algorithm on the socket connection can help a lot.

When working with high volumes of small messages, i found this made a huge difference.

From memory, I believe the socket option for C++ was called TCP_NODELAY

---

As @Jerry Coffin proposed, you can switch to UDP. UDP is unreliable protocol, this means you can lose your packets, or they can arrive in wrong order, or be duplicated. So you need to handle these cases on application level. Since you can lose some data (as you stated in your comment) no need for retransmission (the most complicated part of any reliable protocol). You just need to drop outdated packets. Use simple sequence numbering and you're done.

Yes, you can use RTP (it has sequence numbering) but you don't need it. RTP looks like an overkill for your simple case. It has many other features and is used mainly for multimedia streaming.

[EDIT] and similar question here

---

On the hardware side try Intel Server NICs and make sure the TCP offload Engine (ToE) is enabled.

There is also an important decision to make between latency and goodput, if you want better latency at expense of goodput consider reducing the interrupt coalescing period. Consult the Intel documentation for further details as they offer quite a number of configurable parameters.

---

If you can, the obvious step to reduce latency would be to switch from TCP to UDP.

---

Yes.

Google "TCP frame size" for details.