[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC)：2025-08-27。"],[[["\u003cp\u003eConnection pools are caches of database connections that enhance performance by sharing and reusing connections, using a round-robin system.\u003c/p\u003e\n"],["\u003cp\u003eEach Bigtable client has a connection pool, containing gRPC connections that can each handle up to 100 concurrent streams, managed by Google's middleware.\u003c/p\u003e\n"],["\u003cp\u003eHaving too few connections leads to buffering and increased latency, while too many idle connections result in frequent disconnections and potential server-side cache misses, spiking tail latency.\u003c/p\u003e\n"],["\u003cp\u003eThe default connection pool size is usually sufficient, but adjustments might be needed when experiencing low throughput with high latency, buffered requests, or when using virtual environments where CPU count detection is inaccurate.\u003c/p\u003e\n"],["\u003cp\u003eOnly the Go, C++ and Java client libraries allow the number of connections in each pool to be configurable.\u003c/p\u003e\n"]]],[],null,["# Connection pools\n================\n\nThis topic describes how connection pools work in Bigtable, the impacts\nthat connection pool size can have on an application that uses\nBigtable, and when you might want to change the default connection\npool settings.\n\nAfter you read this page, if you determine that you should change your\nconnection pool size, see [Configuring connection pools](/bigtable/docs/configure-connection-pools) to\nlearn how to determine the optimal size and how to change it. The number of\nconnections in each pool is configurable in your code only when you use the Go,\nC++, or Java client libraries for Cloud Bigtable.\n\nHow connection pools work\n-------------------------\n\nA *connection pool* , also known as a *channel pool*, is a cache of database\nconnections that are shared and reused to improve connection latency and\nperformance. Connections are used in a round robin system.\n\nWhen you use Bigtable, you create a single data client per\napplication process. Each client has one connection pool. Each connection pool\ncontains some number of gRPC connections, which can each handle up to 100\nconcurrent streams. Requests sent through these connections pass through Google\nmiddleware, which then routes them to your table. The middleware layer is made\nup of many load-balanced instances, and each request is routed through the\nmiddleware instance that has the most availability.\n\nYou can think of a *connection* (or channel) like a highway that has up to 100\nlanes, and each lane (stream) can only contain one car (request) at any given\ntime. The limit of 100 concurrent streams per gRPC connection is enforced in\nGoogle's middleware layer, and you are not able to reconfigure this number.\n\nA connection automatically refreshes itself once every hour. Additionally, if a\nconnection has not seen a request in five minutes, the middleware automatically\ndeletes the connection and doesn't recreate it until an additional connection is\nneeded.\n\nBehind the scenes, each channel has a single subchannel. Each subchannel has an\nHTTP2 connection that uses TCP to convert requests to bytes and send them\nthrough the middleware and then to your table. This process is handled\nseamlessly by the Bigtable service, and you don't need to configure\nanything to make it happen.\n\nHow connection pools affect performance\n---------------------------------------\n\nIdeally, you should have enough gRPC connections to handle your requests\nwithout any buffering. However, you should not have so many connections that\nthey are frequently dropped because of lack of use.\n\n### Not enough connections\n\nIf a connection pool does not have enough connections to handle your traffic,\nthe middleware starts to buffer and queue requests. This buffering slows down\nthe traffic, reducing the number of requests per second and increasing latency\nas the requests back up.\n\n### Too many connections\n\nIf a pool has too many connections, meaning some of the connections are idle,\nthe middleware disconnects the idle connections. Then when new requests come\nthrough that require them, these connections are reestablished. This means that\nwhen traffic increases, requests can encounter a server-side cache miss, causing\nextra work and latency. If this happens frequently because of varying traffic\nlevels, this activity can manifest as a perceived spike in tail latency on the\nclient side.\n| **Note:** In most cases, you cannot control the refresh cadence. However, If this tail latency is a concern and you need predictable latency at a low rate of queries per second (QPS), and you are using the [Cloud Bigtable client library for Java](https://cloud.google.com/java/docs/reference/google-cloud-bigtable/latest/overview), you are able to configure the refresh settings using the `BigtableDataSettings.Builder` class. If you are using the [Cloud Bigtable client library for Go](https://godoc.org/cloud.google.com/go/bigtable), see the [Connection Refresh Example](https://github.com/GoogleCloudPlatform/cloud-bigtable-examples/tree/master/go/connection-refresh) on GitHub.\n\nWhen to change the default settings\n-----------------------------------\n\n**The default connection pool size is right for most applications, and in most\ncases there's no need to change it.** Depending on the client library you use in\nyour application, you might not be able to change your connection pool size. The\nnumber of connections in each pool is configurable in your code **only when you\nuse the Go, C++, or Java client libraries for Cloud Bigtable**.\n\nAs a general rule, an ideal connection pool has at least twice the number of\nconnections that it takes for maximum saturation. This leaves room for traffic\nfluctuations. For example, if you have 4 connections and they are each handling\nthe maximum number of requests possible (100), you want to bring the number of\nrequests per connection down to a number between 10 and 50, so the ideal\nconnection pool size is at least double that, or a minimum of 8 connections.\n\nSignals that you should consider changing the number of connections in the pool\ninclude the following:\n\n### Low throughput combined with spikes in client-side tail latency\n\nIf your typical throughput is fairly low, such as less than one request per\nsecond per connection, and you observe periodically high tail latency for your\napplication, you might not be sending enough traffic to keep the connections\nalive. In this case, you might need to lower the number of connections in the\npool. See [Configuring connection pools](/bigtable/docs/configure-connection-pools) to learn how to\ndetermine the right number.\n\n### Buffered requests\n\nIf you observe that requests are stacking up on the client side, this might\nindicate that you are sending more concurrent requests than the connection pool\ncan handle. [Calculate the optimal number](/bigtable/docs/configure-connection-pools), then change\nyour code if you need to.\n\nTo determine whether requests are stacking up, you can use\n[OpenCensus](https://opencensus.io/guides/grpc/java/#examining-metrics) to look at the difference between the\n`grpc.io/client/started_rpcs` and `grpc.io/client/completed_rpcs` metrics.\n\n### Virtual environment\n\nIn some rare cases, the Bigtable client is not able to tell the\nnumber of CPUs that the application is running on and allocates connections as\nif only one CPU is in use. For example, this can happen when you use virtual\nCPU instances in Kubernetes or Docker. If this is evident, you should configure\nthe number of pools [according to the guidelines](/bigtable/docs/configure-connection-pools) based on\nyour application's QPS and latency.\n\nWhat's Next\n-----------\n\n- Learn how to [configure connection pools](/bigtable/docs/configure-connection-pools).\n- Read more about [performance](/bigtable/docs/performance)."]]
