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

Question

I've seen a number of posts regarding disabling the Nagle algorithm in WCF when working on Azure. I've been wondering about if this is only applicable for Azure or if this should be a more generic best practice.

As described on various sources, the Nagle algorithm basically batches small TCP requests into a single larger request. Batching occurs on a per-connection basis.

Most WCF transmissions that I've seen in a professional context of are small blocks of data, sent by a single thread and mostly two-way. I understand that this is not really the ideal situation for the Nagle algorithm.

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

Answer 1

As I understand it, Nagle's algorithm only essentialy helps when the data is streamed in small chunks at a rate falling short of network throughput. For example, if it is a video feed or constant output from some hardware sensor (where real time does not matter, but history does). Imagine the extreme case - all of this data being sent without Nagle's Algorithm byte-by-byte, essentially multiplying the traffic by 41.

On the contrary, when the data is written in one large chunk (SOAP request) and then received in one large chunk (SOAP response), it is of course not useful and even harmful (due to delays). Hence the advices to tourn it off.

So, one can conclude that Nagle's algorighm should be left on for streaming applications (file, video, constant data feed) unless real-time processing matters (console terminal). It is basically a "code of good conduct" for application to not clog the channel with useless traffic (this may be an issue in large datacenters with heavy network load). If the communication is done in request-response mode (i.e.: all data is written in buffer at once - so Nagle's algorithm is not effective), you can turn it off by default.

Answer 2

Nagle should be turned off for protocols that use a lot of small-sized (at TCP/HTTP level) messages. I don't think it's ok to do this always.

Please also note WCF does not necessarily means SOAP. It depends on the bindings used. The message size also depends on the encoding used. WCF is very configurable.

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

But, if your application is using a SOAP binding and you measure that the average message size is more than 1500 bytes (which seems frankly possible with SOAP XML payloads), than it's not worth it.

So, you really need to measure things before taking a decision IMHO - like the Azure guys did, well, maybe they did it after :-). One simple way to measure HTTP message size is to use Fiddler2, especially the statistics tabs (select all message, it will give you the total number of frames, and the total number of bytes).