Strange behavior (delay in connection)

Hello LS friends
I have a question about something strange is happening to us.

We have finally installed our production server in a zone very difficult to reach (guess it... ;) )

the communication from here is slow, but that's not important
so we used a twin machine in the same region to do some connection tests (more in the future to check LOADs)

from the "test" machine we are requesting a very long table to the MAIN LS server and we are getting very fast connections

Let's say that the AVG is 50 msecs to receive back the informations

BUT time to time one attempt
takes 5050 msecs (only one time I've got a 3050 msecs) delay

I'm getting this spurious result let's say 1 out of 30 attempt on AVG

What could be ? Is the LS server in exponential backoff of something ? What could cause a so precise EXTRA delay ?

thank you for your help!
Antonio

Hello Antonio,

The most likely explanation is that the delay is caused by a TCP retransmission of a lost packet.
As far as I know, the TCP uses indeed this kind of exponential backoff.
You can ascertain this with a network capture.

However, lost packets can be recovered in a faster way when they are followed by other packets.
These conditions can be achieved by LS Server configuration, by enlarging the TCP send buffer (see the <sendbuf> element).

In fact, LS Server, by default, enforces a small send buffer, which ensures that, in case of a temporary interruption of the communication, the amount of data blocked is minimal. In fact, during the interruption, subsequent data becomes old and had better be replaced with newer data by conflation, but the Server cannot do that once they have reached the TCP send buffer.
With a small buffer, the TCP would immdiately send the backpressure to the Server, which, in turn, would conflate the data.

However, the default settings only work well when the throughput of the session is small and the packets sent are small either.
When the throughput is larger and packets are larger, a larger send buffer should be configured, in order to take advantage of the TCP mechanisms, as said. The amount of blocked data would also be larger, but still acceptable, considered the high session activity.

You should find the best setting for your scenario with a few tests; for instance, you can start with 5000.
An adaptive mechanism for the send buffer setting is not yet available.

Synthi I think we have the same problem... If you find solution, help me please.

Thank you.