Major Description
The current design allows a single connection from the connection pool to collect a large number of in-flight operations, rather than ensuring a more even spread of operations across connections in the pool.
This can be detrimental when mixing small GET operations with large GET operations, as the small operation may be blocked waiting on the large operation to pass over the network socket. If the small operation were sent on another connection it may complete sooner. A more even spread of operations doesn't guarantee this will be the case, but does make it more likely.
Additionally, when the connection pool is flooded with requests, for example for a batch operation, it tends to recover poorly. This is because many of the operations will timeout before they can complete but they have already been sent to the server. Therefore, these operations are still executed by the server and block other operations that were queued later. This effectively guarantees that the later operations will also timeout, even though they could have succeeded. If operations are instead queued on the client side and never sent if they timeout the SDK will recover better for later operations.