[erlang-questions] 20k messages in 4s but want to go faster!

[Michael Truog]

Johnny Billquist wrote:
> Michael Truog wrote:
>> Matthew Sackman wrote:
>>> On Sat, Jul 11, 2009 at 01:24:46AM +0200, Johnny Billquist wrote:
>>>  
>>>> Nagle is actually a good thing, which improves performance, not
>>>> decrease it.
>>>>
>>>> There is one specific situation when you don't want nagle, and that
>>>> is if you send very little data, and what it to be sent immediately.
>>>> In that specific case, Nagle is an obstruction and should be shut
>>>> off.
>>>>     
>>> Yup. The immediate part shouldn't be underestimated. The improvement to
>>> latency can be significant. If you're doing a lot of client-server
>>> communication, then disabling Nagle can improve throughput
>>> substantially
>>> as the latency comes down thus permitting higher round trips per
>>> second.
>>>
>>> Matthew
>>>   
>> As clarification, disabling Nagle is best for low latency networks and
>> improves throughput.  High latency networks can benefit from the
>> algorithm, so it is generally used unless it is an internal cluster of
>> computers.
>>
>> See http://en.wikipedia.org/wiki/Nagle's_algorithm
>> to see why real-time systems avoid Nagle.
>
> Hmm, I can't see how Nagle would help if you have a high latency
> network. Don't make no sense at all. That's not what Nagle is for.
> That's what you have sliding window protocols for. And large packets,
> large windows and large buffers.
>
> But any high volume connection will benifit from Nagle. Try turning
> off Nagle and do a file transfer, and you could become very
> disappointed with the performance.
>
> What Nagle really aims at, is when you have an application send lots
> of small pieces of data. Without Nagle, each little bit will be send
> it it's own TCP segment. With Nagle, all those small sends will be
> bundled together in a larger TCP segment. Now, Nagle don't neccesarily
> delay data, it only delays data if you have a segment smaller than
> MSS, otherwise it will be send right away anyway, since there is no
> point in delaying that packet to try and aggregate data.
>
> And file transfers are usually not sending data in chunks adapted to
> the MSS, but instead just sends whatever chunk size is convenient for
> the tcp implementation. Nagle will make sure that the link is used as
> efficiently as possible.
>
> As I said from the start, the only time you should disable Nagle is if
> you are sending *little* data, and want low latency. If you have high
> volumes of data, Nagle will help you, by either not interfering at all
> (if your applicion is sending chunks larger that the MSS), or
> aggregating your data into as large IP packets as possible (thus
> reducing the protocol overhead, and thereby improving throughput).
>
> Real time systems should probably avoid Nagle, because they should be
> very concerned with latency. More so than throughput. :-)
>
>     Johnny
>
Sorry for making this thread longer than it needs to be.  For an
understanding of why Nagle's algorithm is used, there is some
information here:
http://searchnetworking.techtarget.com/sDefinition/0,,sid7_gci754347,00.html
"... this process (called /nagling/) increases the efficiency of a
network application system by decreasing the number of packet
<http://searchNetworking.techtarget.com/sDefinition/0,,sid7_gci212736,00.html>s
that must be sent."

So decreasing number of packets helps with high latency networks.  It
also makes sense that most real-time systems don't care much about high
throughput, but are instead more focused on small, low latency
messages.  However, I can imagine there are real-time systems where
throughput is a concern (in addition to latency).