It makes sense that changing the number of connections will make a huge difference since the HTTP/1.1 case will only allow 1 concurrent request. My hope was that even if I use HttpClient.setMaxConnectionsPerDestination(200), I would still see an improvement on the HTTP/2 side.
The idea is that there is a limit on the rate of IP packets sent between machines. Therefore, even when using multiple connections there is a limit to the amount of traffic that can pass between two machines. (Note: number of packets, not total bandwidth)
HTTP/2 uses a single TCP connection for multiple outstanding requests. Since TCP is a byte-pipe, it can allow multiple requests to be transmitted in a single IP packet. This would allow the request rate to increase while the packet rate remains the same, thus increasing throughput.
The request rates I have seen for HTTP/1.1 are in the
range for most tests I've done on Linux/MacOS systems (50k-75k
packets/s). Using a single TCP socket with multiple requests per packet
optimization, I've seen much higher throughput (200k-1000k requests/s).
Unfortunately, my testing used a primitive protocol and I haven't spent
the time to see if I can repeat the results using HTTP.
Thanks for the advice. I'll keep investigating and see if the idea has any merit.
