It depends on exactly what and how you're measuring and why. TLS has a non-trivial bootstrap cost, due to the need for extra network round-trips during establi

It depends on exactly what and how you're measuring and why. TLS has a non-trivial bootstrap cost, due to the need for extra network round-trips during establishment (mitigated with 0-RTT, if available), the additional byte overhead of certificate exchange (which can be substantial relative to small payloads if you have a long chain or are sending unnecessary certs, and more so if you're using RSA keys), and the cost of performing the crypto operations for the public key part and key exchange. So if your use-case is "client arrives from the blue with a one-off API request and latency is important" then you are going to suffer with TLS. If this is a web application (on the other hand), then what's actually going to happen is that the browser is going to establish HTTP/1.1 connections over TLS to the load-balancer, keep them alive, and re-use them. Assuming a well-configured load-balancer, it's also going to have the same from it's back-end to your actual service implementation. However, once that's done, the only necessary overhead is the symmetric key stuff (microscopic) and maybe rekeying in long sessions. Using curl to do a one-and-done connection to your service (as suggested by another poster) will give you an estimate which is only relevant to the first use case I described.