LCDS – eking out the last bit of performance – socket-tcp-no-delay-enabled

I had an opportunity too look into eking out every last bit of performance on an LCDS RTMP channel and came across this property:

socket-tcp-no-delay-enabled

The docs that describe this stuff is here:
http://livedocs.adobe.com/livecycle/8.2/programLC/programmer/lcds/lcconfig_4.html

The docs seem to say that the “socket-tcp-no-delay-enabled” setting is a property of an NIO socket server.
The section that describes configuring NIO RTMP seemed wrong to me or at least has me confused.

in the LCDS install dir: resources\config\services-config.xml (this is a good additional resource for configuration parameters)

this comments say:

Which don’t really help clarify things for me.

After speaking with Seth and Jeff from the LCDS engineering team, they were able to set me straight (and then some Image may be NSFW.
Clik here to view. ).

Socket settings are up to the OS. Adjusting that is OS dependent and I don’t have any steps to offer offhand.
The default for this socket setting is false (meaning the Nagle algorithm is enabled) on various platforms that engineering investigated (Mac OS X Version 10.4.10, Windows XP Version 2002 Service Pack 2, Linux 2.6.9-24.ELsmp). The Java Socket API let’s you tweak these (but in some cases, such as send/receive buffer sizes, invoking a setter is just a request/hint that may be ignored by the platform). It’s best to configure these in LCDS config, so your desired settings are only applied to sockets that LCDS is managing.

When a Socket’s no-delay is false, this means that the Nagle algorithm is enabled. By overriding the default, setting this to ‘true’ in config, you’ll disable the Nagle algorithm.

The Nagle algorithm was designed to help with congestion avoidance for TCP-based applications like Telnet, which may send a single character per TCP packet, leading to lots of unnecessary packets and overhead. With the algorithm enabled, as long as there’s an outstanding un-acked TCP packet the sender will buffer any further bytes to send until it has a full packet’s worth or until it receives the outstanding ack it’s waiting for. So you get something like send – buffer –buffer –buffer – send – buffer … So with Nodelay on, the latency of small messages is reduced but overall throughput probably goes down a bit if you send lots of small messages (i.e. less than a packet size). With nodelay off, smaller data writes (i.e. less than the MTU) are held so they can be combined with other small writes.

Both RTMP and HTTP are just bytes over a TCP socket, so whenever RTMP data or an HTTP response is written back to the client, this algorithm will come into play as the bytes are put on the network.

This is where the docs where incorrect (and they are being fixed as we speak.)
In order to configure a RTMP channel to set the socket-tcp-no-delay-enabled property you would do something like this:

HTH

-Kyle