feat: Improve upon the default gRPC Connection Pool size

[cindy-peng]

The current Java SDK uses a default gRPC connection pool with only one channel . This can cause performance issues for clients with high request rates (over 100 queries per second) because they may experience throttling.

To address this, this PR update proposes changing the default connection pool settings to allow for multiple channels (minimum 1, maximum 4). This should improve performance for clients with high request rates, without requiring any changes to their code. Customers can still customize the connection pool settings if needed.

Please refer here for more details:
configure a more reasonable default grpc connection pool config

[gkevinzheng]

Could you use constants for gRPC minimum and maximum channel counts?

[daniel-sanche]

LGTM, but I agree with Kevin that constants would be good to have

[cindy-peng]

Could you use constants for gRPC minimum and maximum channel counts?

Good catch! Fixed.

[generated-files-bot]

Warning: This pull request is touching the following templated files:

• .github/workflows/ci.yaml

[gkevinzheng]

LGTM

[jimit-j-shah]

Have you tested and verified that this indeed improves latency at the SDK? Running a client with high enough operation qps should be able to verify this.

Also, you can use tcpdump or netstat to verify the work done over each gcp connection .

[cindy-peng]

Have you tested and verified that this indeed improves latency at the SDK? Running a client with high enough operation qps should be able to verify this.

Also, you can use tcpdump or netstat to verify the work done over each gcp connection .

Hi Jimit, I ran some benchmark tests with 1000 QPS and this change improved lookup and update average latencies by 2%-6%: go/connection-pooling-benchmark. I think this is a good indicator that the change improved latency at the SDK.