Adaptive Connection Pool Throttling based on Latency

This is a good idea.  I'd like to ask for some further clarification on it.
Is the problem from the connection pool creating additional new connections to the database to try to handle the load, as suggested by "open more connections to handle the queue"?
Or is the problem from the connection pool allowing too many existing connections to be used at once, as suggested by "increased number of concurrent connections"?

In either case, there are going to be situations where measuring response time will not always be accurate or useful.  For example, some requests to a backend might have a lengthy response time because the data they are trying to access is locked while the owner of the lock wants to make additional requests to the same backend of data that is not locked before releasing the lock.  In that case, throttling could make things worse and delay the release of the locks that are causing some lengthy response times.  Alternatively, some requests might take longer than others because they are more complex than others.  It seems like to get this right the connection pool would need to make extra requests that are all identical (and don't involve locking) -- something like JDBC's Connection.isValid method -- to be able to make an accurate comparison. There would be the tradeoff of the cost of the extra requests, and how often these measurable requests are made, also impacting the granularity and responsiveness of the autotuning.