4 ms·
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:
by Zr40 11y ago
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
- Ono-Sendai 11y agoI 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?
- Zr40 11y agowrk[1] does appear to reuse a connection for each request. [1] https://github.com/wg/wrk https://github.com/wg/wrk
- hirsin 11y agoAny 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.
- Zr40 11y agoThat'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.