> On Apr 5, 2019, at 8:23 AM, Anthony Baker <aba...@pivotal.io> wrote: > > One question: if I’m using thread-local connections ho does that affect pool > sizing? Are thread-local connections included in the overall pool size or > accounted for separately?
On the client side thread local pool just pulls from the primary pool so any limit on the primary pool applies to the thread local. By default the client pool is unbounded so it isn’t a problem. If you did bound it to like 100 connections and had 200 threads then 100 of those threads will fail to get connections. It really effects the server more. Assuming you have 4 servers with normally distributed partitioned data, then a 1000 thread client doing single hop operations would have 4000 connections, 1 to each server for each thread. The other issues is that 3/4 of those connections are not doing anything at any given time. Given the default limit of 800 connections on the server you can see how quickly thread local connections can put you over that limit. The fixes to the primary pool contention allow us to do 1000 threads (or more) into the primary pool. So with this same client, doing normally distributed single hop operations, you could expect about 1000 connections, about 250 connections to each server. The win is that all these connections are hot, not idle. > We may want some explicit release notes if a user would need to resize their > pools during an upgrade. We could provide some documentation to suggest they may be able to scale down their max limits on the servers. -Jake
