Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

>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.



Because, 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.


Sure, 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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: