https performance

[col.o...@gmail.com]

I made a minimal http and https server to benchmark with siege and found a huge performance difference. http serves 5000+ trans/sec while https  averages 53 trans/sec.
source https://gist.github.com/anonymous/95136ccbfe4b8a0f0924

I have no previous experience with ssl but articles Iv read lead me to believe that the performance difference should  be negligible. So I setup a nginx server to compare and found similar performance of 6-7k trans/sec for http and 220-400 trans/sec for https. nginx ssl performance seems to vary based on cipher settings
nginx.conf https://gist.github.com/anonymous/a1c8367924aac8668e8b

AM I DOING SSL WRONG?

[Ingo Jaeckel]

I am enforcing HTTPS-only on a Go GAE app. In load tests I achieved up to 2000 requests/s on the smallest instance type (F1). At least in this setup I didn't notice any performance problems. I haven't compared it to HTTP though.

Can you provide a few details about the request/response bodies you are sending/receiving? In my example the response body is just 4 bytes long and my request body was empty.

Thanks,

Ingo

[Qian Qiao]

A typical reason for the slow HTTPS performance is the massive https handshake cost.

In real world situations, you should probably consider setting proper cache control headers for content that don't change as often.

-- Joe

[col.o...@gmail.com]

It looks like go's crypto lib has support for the AES instruction set. Unfortunately my laptop processor does not have AES-NI.  Would i need to build the go binary on a cpu with AES-NI for it to be used to serve https connections on a server with a proper processor?

On Thursday, October 9, 2014 9:00:00 PM UTC-4, col.o...@gmail.com wrote:

[mjste...@gmail.com]

Hi,

It's not the AES symmetric encryption that is likely to be slow. It's the asymmetric handshake (1024+ bit keys, private/public) at the start of the SSL/TLS session, as Qian said. Try benchmarking an initial connection, then a number of requests over the that same connection. Looking at the Config struct there is also room for a ClientSessionCache which enables session re-use.

Regards

Matt 

[col.o...@gmail.com]

I tried siege -H "Connection: Keep-Alive" -q -c 100 -b --time=10s
10114.16 trans/sec for http and  51.93 trans/sec for https

[mjste...@gmail.com]

I've never used siege so hopefully someone can suggest or confirm it'll do multiple requests on the same session (maybe the -r option?). I've used Apache Jmeter to do some simple benchmarks, its more complex than siege but also more configurable. Maybe write a simple go client... :)

[Benjamin Measures]

Setting a header doesn't make it so.

Check out the siege FAQ [1] and read the configuration file [2].

[1] http://www.joedog.org/siege-faq/#a07
Support for persistent connections is poor. Siege prefers Connection: close

[2] http://fossies.org/linux/siege/doc/siegerc.in
TRIPLE CAUTION: don't use keep-alives until further notice

[Andrew Bursavich]

FWIW (not much), here's a sample of my benchmark results for the code you posted. Both tests used 50 concurrent connections that were kept alive and reused. Client and server both ran on my laptop pegging all 8 cores.

HTTP
  Total:     1m0.00445877s

  Slowest:   115.064349ms
  Fastest:   97.172µs
  Average:   996.998µs
  Requests:  2717001  (45279.985/s)
  Received:  350MB    (5.8MB/s)
  Sent:      331MB    (5.5MB/s)

HTTPS
  Total:     1m0.011442533s
  Slowest:   207.953846ms
  Fastest:   121.66µs
  Average:   1.12181ms
  Requests:  2437320  (40614.255/s)
  Received:  388MB    (6.5MB/s)
  Sent:      368MB    (6.1MB/s)

[col.o...@gmail.com]

Thanks for the tip about siege. I setup a Jmeter load test with keep alive turned on and the throughput of https reached 5349.4/sec.