4 ms·

What's a typical latency increase (on a purely localhost) of adding SSL/TLS to nginx? I've been doing some testing, and I see an increase of about 40-60ms, jus

What's a typical latency increase (on a purely localhost) of adding SSL/TLS to nginx? I've been doing some testing, and I see an increase of about 40-60ms, just for initial connection server compute. Is that normal? How does one reduce the initial SSL/TLS connection compute time? My web app responds in 1-2ms. Adding another 40-60ms on top of for https that wrecks latency.

legojoey17 9y ago
I'd love to figure this out and why that's the case because this happens to me too.
elithrar 9y ago
a) what is that as a fraction of the total RTT in "real world" conditions (not localhost) b) with session tickets configured, do you see this increase consistently for the same client? c) would your users find it acceptable to have the occasional 50ms hit on a full handshake in order to get authentication & encryption? would they even notice (see 'a')
- mozumder 9y ago
  a) It's a pretty large percentage (~50%) for viewers within my target critical region (east coast) but it becomes less important when accessed worldwide. b) Session tickets cuts it from 60ms down to about .5ms extra delay (when loadtesting with a keepalive https connections) so this is really only an initial handshake problem. c) The localhost full handshake latency problem is really a proxy to the real problem: the CPU load. TLS/SSL is adding a lot of compute requirement to each initial connection. This becomes important as I have to deal with celebrity content, where a single Twitter link can lead to hundreds of thousands of incoming connections within a few minutes. TLS/SSL handshake compute requirements really need to be sped up somehow..
  - pfg 9y ago
    60ms sounds like too much. How are you measuring this, and what does your TLS config look like? A quick test with ab (-n 1 -c 1) against a nginx instance shows about 5ms for me, on an Intel E3-1245 V2 @ 3.40GHz. This is with a P-384 key, so it would be even less with P-256 or RSA-2048 (which, IIRC, have fast assembler implementations in openssl).
Klathmon 9y ago
In addition to what elithrar is saying, take a look at some of the stuff at https://istlsfastyet.com https://istlsfastyet.com Things like TLS False Start, TLS Resumption, TCP Fast Open, and more can really help reduce that pretty well. Also, take a look at the book linked at the bottom of that page which includes a pretty comprehensive section on improving RTT and TLS speeds in general. (https://hpbn.co/transport-layer-security-tls/ https://hpbn.co/transport-layer-security-tls/)
z3t4 9y ago
An option might be to not upgrade to SSL until the user logs in or interacts with the app.

legojoey17 9y ago

I'd love to figure this out and why that's the case because this happens to me too.

elithrar 9y ago

a) what is that as a fraction of the total RTT in "real world" conditions (not localhost) b) with session tickets configured, do you see this increase consistently for the same client? c) would your users find it acceptable to have the occasional 50ms hit on a full handshake in order to get authentication & encryption? would they even notice (see 'a')

mozumder 9y ago
a) It's a pretty large percentage (~50%) for viewers within my target critical region (east coast) but it becomes less important when accessed worldwide. b) Session tickets cuts it from 60ms down to about .5ms extra delay (when loadtesting with a keepalive https connections) so this is really only an initial handshake problem. c) The localhost full handshake latency problem is really a proxy to the real problem: the CPU load. TLS/SSL is adding a lot of compute requirement to each initial connection. This becomes important as I have to deal with celebrity content, where a single Twitter link can lead to hundreds of thousands of incoming connections within a few minutes. TLS/SSL handshake compute requirements really need to be sped up somehow..
- pfg 9y ago
  60ms sounds like too much. How are you measuring this, and what does your TLS config look like? A quick test with ab (-n 1 -c 1) against a nginx instance shows about 5ms for me, on an Intel E3-1245 V2 @ 3.40GHz. This is with a P-384 key, so it would be even less with P-256 or RSA-2048 (which, IIRC, have fast assembler implementations in openssl).

Klathmon 9y ago

In addition to what elithrar is saying, take a look at some of the stuff at https://istlsfastyet.com https://istlsfastyet.com Things like TLS False Start, TLS Resumption, TCP Fast Open, and more can really help reduce that pretty well. Also, take a look at the book linked at the bottom of that page which includes a pretty comprehensive section on improving RTT and TLS speeds in general. (https://hpbn.co/transport-layer-security-tls/ https://hpbn.co/transport-layer-security-tls/)

z3t4 9y ago

An option might be to not upgrade to SSL until the user logs in or interacts with the app.