HTTPS performance #25066
-
Hello. This is a general topic, but I was hoping if you guys had any inputs. We have been contemplating using encrypted communication inside our private networks that runs behind a single secured endpoint. We were trying to analyze the performance impact of switching from HTTP to HTTPS and it looks like the throughput (requests/second) drops close to ~half of what it was when using HTTP. The analysis was done using a simple client/server application. Server: Standard D4s v3, 4 vCPUs, 16 GiB RAM, Windows 2012-R2 Datacenter Server setup:
Startup has a single configure method:
Client: Standard DS4 v2, 8 vCPUs, 28 GiB RAM, Windows 2012-R2 Datacenter We just wanted to put this out there and see if anything looks off, and if there were any server specific options that could diminish this gap. |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 1 reply
-
This is expected, and known. We already track this metric, and here is our result on Windows with a Json payload: Also your example is theorically a best case, since you are reusing connections. It might be worst in production if you have short lived connections, as the https handshake will be re-executed. You might try to see if adding an ssl termination proxy like nginx would improve the performance, but it might not be the case depending on the actual load you get. This kind of "issue" is hardly actionable, as you obviously can't get as fast as without https, and it's hard to say what is "acceptable". Also depending on the payload and the server-side code results will change. Our current goal is to compare our https performance to other platforms so we understand if there are gaps we can work on. |
Beta Was this translation helpful? Give feedback.
This is expected, and known. We already track this metric, and here is our result on Windows with a Json payload:
Also your example is theorically a best case, since you are reusing connections. It might be worst in production if you have short lived connections, as the https handshake will be re-executed.
You might try to see if adding an ssl termination proxy like nginx would improve the performance, but it might not be the case depending on the actual load you get.
This kind of "issue" is hardly actionable, as you obviously can't get as fast as without https, and it's hard to say what is "acceptable". Also depending on the payload and the server-side code results will change.
Our curr…