Stability and impract of TCP Fast Open

We have a sharded cluster where each shard has a 5-node replica set spread across 5 physical data centers. Our mongos instances are located on an app servers and can have 150ms latency because they are on the other side of the planet. I stumbled across --tcpFastOpenServer and thought it could significantly reduce connection setup latency while also reducing the number of needed pooled connections (since creating a new connection wouldn’t require a 3-way handshake).

Has anyone here turned this setting on? If so, do you have any data or anecdotes of how well it worked? Anyone have any unexpected negative results? I haven’t seen much on the forums discussing this.

The documentation seems to indicate this is on by default if both the client and server support TFO. My db.serverStatus() output contains the following:

    tcpFastOpen: {
      kernelSetting: Long("1"),
      serverSupported: true,
      clientSupported: true,
      accepted: Long("0")
    },

Is there a way to see if TFO is actually already being used?

This tells it’s not being used. From the documentation: network.tcpFastOpen.accepted indicates the total number of accepted incoming TFO connections to the mongod/mongos since the mongod/mongos last started.

Any tips on how to make both the client and server use tcpFastOpen? it seems like both are supported. I still see the accepted count at 0.

Depends on the OS, but generally you should follow the documentation https://www.mongodb.com/docs/manual/reference/parameters/#mongodb-parameter-param.tcpFastOpenServer

On Linux /proc/sys/net/ipv4/tcp_fastopen is the parameter to look at (both client and server).