Hacker News Reader

Hacker News

Comment by Ono-Sendai | Hacker News Reader

Full thread

Ono-Sendai

I'm currently adding https (TLS) support to my blog, using LibTLS (part of LibreSSL).

My initial impressions are that TLS handshake is very computationally expensive.

Stress testing my webserver with plain HTTP connections:

7980.2744 queries/s

With HTTPS (TLS) connections:

23.059916 queries/s

The slowdown is due to high CPU usage.

I certainly wouldn't classify that as fast!

I've only done a bit of work on this so it's possible I'm misusing the LibTLS API however.

View on HN

How did you measure this?

When measuring on one of my servers that exposes both HTTP and HTTPS, there doesn't appear to be any significant difference.

HTTP:

  % wrk http://hostname
  Running 10s test @ http://hostname
    2 threads and 10 connections
    Thread Stats   Avg      Stdev     Max   +/- Stdev
      Latency     5.11ms    5.42ms  62.85ms   96.08%
      Req/Sec     1.10k   224.03     1.31k    87.04%
    17703 requests in 10.01s, 6.89MB read
  Requests/sec:   1768.57
  Transfer/sec:    704.58KB

HTTPS:

  % wrk https://hostname
  Running 10s test @ https://hostname
    2 threads and 10 connections
    Thread Stats   Avg      Stdev     Max   +/- Stdev
      Latency     4.75ms    4.09ms  50.37ms   96.48%
      Req/Sec     1.10k   228.86     1.34k    79.35%
    17014 requests in 10.01s, 8.39MB read
  Requests/sec:   1700.32
  Transfer/sec:    858.38KB

I tested it with some of my own code, 8 threads making requests to my server at localhost.

Does this program 'wrk' re-establish a connection for each request, or is it re-using them?

wrk[1] does appear to reuse a connection for each request.

[1] https://github.com/wg/wrk

Any idea how HTTPS manages to have a significantly higher throughput? At first blush this doesn't quite pass the sniff test - it looks like there's another factor in play here.

That's probably because the response to this particular https URL is larger; http on this server simply redirects to https and is therefore a smaller response.

Not that this matters here; the top level comment measured requests per second, not bytes per second. If anything, the smaller response for http would give http an advantage in this comparison.

One problem is "TLS" isn't just one thing to understand and test against. TLS involves dozens of optional cypher suites and each one has a unique performance profile.

Just for fun, add !kEDH to your server's list of allowed cyphers then see how your performance changes.

Another performance impact some people overlook: your key size is also computationally expensive. There's not much reason to have a key larger than 2048 bits, so if you made a 4096 bit key just for fun, roll it back to a 2048 bit key for better performance too (plus, your mobile viewers will thank you for not burning their battery life needlessly).

What key size and cipher suite are you using? (If you're willing to post the URL, we can have a much more informed discussion, but a sanitized copy of an SSL Labs test or even of `openssl s_client -connect localhost:443` is also workable.)

Also, what hardware are you using? This site is aimed more at companies who fear of losing business because their site is slow, than people hosting a blog on a home server; if you don't have hardware-accelerated crypto (like most server-class machines have, whether or not you explicitly looked for it) its argument is less valid.

I'm using all the defaults, as provided by LibTLS, so I'm not sure. I'll have a poke round and tell you later.

The TLS support is not deployed to the internet so posting a URL wouldn't be very helpful.

Hardware is my Ivy bridge i7 with 4 physical cores.

Yeah, Ivy Bridge is new enough. Are you negotiating an AES-GCM suite? Also, are you using a 2048-bit key if you're doing RSA? (A larger key almost certainly provides no more security, since your intermediate is almost certainly 2048-bit, and will noticeably slow down handshakes.)

LibTLS tells me what was negotiated was 'ECDHE-RSA-CHACHA20-POLY1305'

Edit: some more output:

  New, TLSv1/SSLv3, Cipher is ECDHE-RSA-CHACHA20-POLY1305
  Server public key is 1024 bit
  Secure Renegotiation IS supported
  Compression: NONE
  Expansion: NONE
  No ALPN negotiated
  SSL-Session:
      Protocol  : TLSv1.2
      Cipher    : ECDHE-RSA-CHACHA20-POLY1305

Yep. Keep-alive is your friend. If you use Apache or similar web server where keep alive means using a lot of RAM, you can place HAProxy or similar load balancer in front of it. HAProxy keeps the connections with browser alive, while connections between HAProxy and backend web server are closed and re-established all the time. Of course, this means that SSL is terminated on the load balancer and not the webserver.

The site and the linked resources talk about handshakes: only a small percentage of your traffic should actually require a full handshake, since most of your users are going to request multiple files. Basic benchmarks don't do that and therefore provoke a worst-case you are unlikely to see in real usage. Might be relevant for APIs, ad servers or similar though.

Reply on news.ycombinator.com