Performance boost through encryption

i developed a tcp-c ( benchmark application to evaluate the performance of different newsql dbms.
except of the results in cockroach everything seems reasonable.
cockroach is the only db which shows a performance improvement (~ 20% faster) when the cluster is secured.
i use the same environment setting (hw and sw) and tried it several times.

are you familiar with this behaviour?
are there some dependencies which are activated when the cluster is secured which could lead to a performance improvement?

i am thankful for every hint.

This is definitely unexpected. I think we’re currently using essentially the same code paths for secure and insecure modes, except for the use of TLS (there were some differences here in the past, though). There are two reasons I can think of that TLS might speed things up:

  • TLS has optional compression support (it’s discouraged these days because it can leak information, at least when used in HTTPS: If that’s being used, it might improve performance by reducing network traffic (the postgres network protocol compresses pretty well).
  • Proxies may do funny things with plaintext traffic, but they have to pass TLS traffic straight through. Is there anything on your network that might be interfering with the data?

compression is not activated. tls 1.2 with cipher suite ECDHE-RSA-AES128-GCM-SHA256 were used for the communication between client - cluster and internode communication.
client and cluster are in the same lan. there are no proxies between the cluster and the client, thus other dbms are working as expected.

i created a new test environment (os + cluster) and have come to the same result.
before i give it another try i wanted to check if it is somehow related to the implementation of the encryption feature.
i will post as soon as I know what the cause of the problem was.
thank you!

Just throwing it out there (without looking a bit at source) is it could be the ssl implementation interacts with naggle better (possibly because of directly or the way buffers work, ie: without encryption it sends several little writes triggering naggle instead of one network write which will cause things to be non optimized, and maybe encryption forces things in the buffers of full requests)

If it is naggle or something, it should be evident on a packet trace comparing the two methods that has at least ms accurate time stamps.