Tune connection pool behavior: timeouts, limits + connection selection

[slackhappy]

I'm not 100% sure, but I think ConnectionPool is using an LRU scheme. For connections from the phone, our app would probably perform better with an MRU scheme. The reason is that older connections are more likely to have their tcp connections reset, either by the client or by the server (though we are now setting all of the timeouts from the ConfigureTimeouts.java recipe).

In our particular case, reconnecting can be pretty expensive. Our DNS load balancing usually causes each new resolution to go to a different SSL terminator, meaning we may not resume the SSL session, so we also have to redo the handshake, but in any case, it would would be preferable to just use the connection whose tcp connection is the most likely to be active, which is the one that was just returned to the pool.

We are currently trying to mitigate by making sure our keepAlive timeout is slightly smaller than the tcp timeouts (thereby ensuring any member selected by ConnectionPool.get is probably alive), but it would be nice to also play around with a different selection policy like MRU.

Any advice on connection best practices, anything I am missing or misinterpreting?

Thanks!

[swankjesse]

The current implementation prefers to return connections that have been in the pool the longest. This strategy wins for some usage patterns, and loses for others.

I'd love to get some data and see some experiments here. Not exactly sure how to conduct that though, particularly on reporting real-world behavior back.

[aaronzirbes]

👍

[swankjesse]

By the way, it’s very straightforward to implement this with our newest ConnectionPool rewrite. Instead of returning on the first connection that matches, return either the one with the oldest idle period or the newest idle period.

Anyone who makes that change & does experiments it in the wild has the option of significantly improving OkHttp’s performance for everyone!

[yschimke]

I don't think this last comment is still relevant. This ticket is effectively a dupe of #4530 and #5191