Configure connection pools
Some Cloud Bigtable client libraries let you configure the number of gRPC channels in a client's connection pool, also known as a channel pool. In most cases, the default configuration is correct, and there is no need to change it.
Connection pools are automatically resized as needed when you use the Cloud Bigtable client library for Java version 2.23.0 or later, and when you use the Cloud Bigtable HBase client for Java version 2.9.1 or later.
This page describes how to determine the optimal connection pool size for your application, and it presents code snippets that show how to configure the connection pools.
Before you read this page, read the overview of Bigtable connection pools to learn how they work and whether you should change yours.
The following client libraries offer connection pooling and let you configure the number of pools:
- Go client library for Cloud Bigtable
- Cloud Bigtable HBase client for Java
- Cloud Bigtable client library for Java
- Cloud Bigtable C++ client library
Determine the best connection pool size
Ideally, to leave room for traffic fluctuations, a connection pool has about twice the number of connections it takes for maximum saturation. Because a connection can handle a maximum of 100 concurrent requests, between 10 and 50 outstanding requests per connection is optimal. This concept is described in more detail in Connection pools.
Monitor your traffic after making changes and adjust the number of connections in your pool if necessary.
The following steps help you calculate the optimal number of connections in your channel pool using client-side metrics such as those available from OpenCensus.
- From your client-side metrics, gather the following information:
- The maximum number of queries per second (QPS) per client when your application is running a typical workload.
- The average latency (the response time for a single request) in ms.
- Determine the number of requests that you can send serially per second by dividing 1,000 by the average latency value.
- Divide the QPS in seconds by the number of serial requests per second.
- Divide the result by 50 requests per channel to determine the minimum optimal channel pool size. (If your calculation is less than 2, use at least 2 channels anyway, to ensure redundancy.)
- Divide the same result by 10 requests per channel to determine the maximum optimal channel pool size.
These steps are expressed in the following equations:
(QPS sec ÷ (1,000 ÷ latency ms)) ÷ 50 streams = Minimum optimal number of connections
(QPS sec ÷ (1,000 ÷ latency ms)) ÷ 10 streams = Maximum optimal number of connections
Example
Your application typically sends 50,000 requests per second, and the average latency is 10 ms. Divide 1,000 by 10 ms to determine that you can send 100 requests serially per second. Divide that number into 50,000 to get the parallelism needed to send 50,000 QPS: 500. Each channel can have at most 100 requests out concurrently, and your target channel utilization is between 10 and 50 concurrent streams. Therefore, to calculate the minimum, divide 500 by 50 to get 10. To find the maximum, divide 500 by 10 to get 50. This means that your channel pool size for this example should be between 10 and 50 connections.
Set the pool size
The following code samples demonstrate how to configure the number of pools in the client libraries that let you set the pool size.
Go
HBase
This sample is applicable only for client library versions earlier than 2.9.1, when automatic resizing was introduced.
Java
This sample is applicable only for client library versions earlier than 2.23.0, when automatic resizing was introduced.