3 ms·
Am I reading correctly that there is a huge difference in http versus SSL requests per second? e.g. in the Bare Metal 1 CPU case it's 48k http to 800 SSL? I h
by ALittleLight 5y ago
Am I reading correctly that there is a huge difference in http versus SSL requests per second? e.g. in the Bare Metal 1 CPU case it's 48k http to 800 SSL? I had no idea the performance impact of SSL was that huge, if this is correct.
- jcims 5y ago>The Ixia client sent a series of HTTPS requests, each on a new connection. The Ixia client and NGINX performed a TLS handshake to establish a secure connection, then NGINX proxied the request to the backend. The connection was closed after the request was satisfied. I honestly struggle to understand why they didn't incorporate keepalives in the testing. Reusing an existing TLS connection, something done far more often than not in the wild, will have a dramatic positive effect on throughput.
- mlyle 5y agoBecause, why bother? The symmetric encryption itself is cheap. We have datapoints for A) 0% SSL handshake workload per connection and B) 100% SSL handshake workload per connection. A reasonable step is just to solve the linear system--- 800 (s+r) = 1 48000 r = 1 and go from there for preliminary sizing. And, when you need detailed sizing, you should be using the real data from your real application. E.g., if it's reused 6 times, we'd expect around 4400 reqs/second from one core.
- jcims 5y agoSure, for a first order approximation that works well. I still think there’s something worth exploring here relative to bare metal vs hypervisors around AES-NI passthrough and cipher suites. My reaction came from the fact that someone that doesn’t understand how much cheaper symmetric encryption is might look at this and just think wow there’s no way I’m using SSL on my back end.
- kevin_thibedeau 5y agoYou need to breakout full handshakes from reconnects with a ticket.
- vorpalhex 5y agoThey were measuring ssl handshakes.