Hi Aliaksandr, thanks for your comment! Regarding your first question, I've created a new class to try out different combination for the configuration of the connection pool, and on it I executed the 4 thousand requests 10 times and also, increased as you said the max total connections available to the http client and the default max connections per route. After running with some combinations, with a max of 1000 connections and 250 per route, I noticed that there was no impact on the latency of the requests. I gathered the times on this file - github.com/MateusTymoniuk/ApacheHttpPoolConnectionComparison/blob/main/measured-latencies.csv, containing the p50 and p90 percentiles. As of the second question, I've updated the repository to use version 5 of the apache httpclient lib, and mostly the code is the same, just changing the packages in which the classes comes from. I also measured the percentiles for this one, but only using 1000 connections with a max of 250 per route, and comparing to the version 4, I also didn't see any impact on the requests times, which to me is because even though the lib can use http version 2, the json-server cannot use this protocol version, which made the whole communication to be synchronous at the end. A nice scenario to test on the future would be to send the requests to a server that has such capabilities, and using the multithreaded approach. Is important to remind again here that those requests are sent to a local json-server. On a real scenario, the latencies should vary more as the servers which we're making the requests to will behave (or misbehave in this case) on lots of different ways.

The only time a new connection is created is when there is a new request and there is no connection already available in the pool. So, increasing the number of connections by themselves would not do much.