Is the Nagle algorithm in WCF / SOAP useful at all?

Question

I saw some reports of disabling the Nagle algorithm in WCF while working on Azure. I was wondering if this is only applicable to Azure, or if this would be a more general practice.

As described in various sources, the Nagle algorithm basically executes small TCP requests into one larger request. Packing takes place based on each connection.

Most of the WCF transmissions that I have seen in a professional context are small blocks of data sent in a single stream and mostly two-way. I understand that this is not an ideal situation for the Nagle algorithm.

So ... Is my conclusion correct that it is best to always disable it when working with WCF or SOAP, regardless of context?

Answer 1

As I understand it, the Nagle algorithm is very important when data is transmitted in small pieces at a speed that does not match the network bandwidth. For example, if it is a video stream or a constant output from some hardware sensor (where in real time it does not matter, but history does). Imagine an extreme case - all this data is sent without the Nagly Byte algorithm, essentially increasing traffic by 41.

On the contrary, when data is written in one large fragment (SOAP request) and then received in one large fragment (SOAP response), this, of course, is not useful and even harmful (due to delays). Therefore, tips for completing it.

So, we can conclude that Nagle algorighm should be left on for streaming applications (file, video, constant data stream) if real-time processing is not required (console terminal). Basically, this is a "code of good behavior" for the application, so as not to clog the channel with useless traffic (this can be a problem in large data centers with a large load on the network). If the communication is performed in a request-response mode (that is: all data is written to the buffer at the same time), so the Nagle algorithm is inefficient, you can disable it by default.

Answer 2

Nagle should be turned off for protocols that use many small messages (over TCP / HTTP). I don’t think it’s normal to always do this.

Also note that WCF does not necessarily mean SOAP. It depends on the bindings used. The message size also depends on the encoding used. WCF is very customizable.

WCF can use, for example, JSON. So, let's say you are building a server application on WCF + JSON + REST, and the average JSON payload is small (say less than 1,500 bytes, which means ~ 1,500 characters, since JSON uses UTF-8 by default), which is probably worth it .

But if your application uses SOAP binding, and you measure that the average message size is more than 1500 bytes (which, apparently, is possible using SOAP XML data), than this is not worth it.

So, you really need to measure things before making an IMHO decision - as the guys from Azure did, maybe they did it after :-). One easy way to measure the size of HTTP messages is to use Fiddler2 , especially the statistics tabs (select the whole message, it will give you the total number of frames and the total number of bytes).