Pool di connessione

Questo argomento descrive il funzionamento dei pool di connessioni in Bigtable, gli impatti che le dimensioni del pool di connessioni possono avere su un'applicazione che utilizza Bigtable e quando potrebbe essere opportuno modificare le impostazioni predefinite del pool di connessioni.

Dopo aver letto questa pagina, se ritieni di dover modificare la dimensione del pool di connessioni, consulta la sezione Configurazione dei pool di connessioni per scoprire come determinare la dimensione ottimale e come modificarla. Il numero di connessioni in ogni pool è configurabile nel codice solo se utilizzi le librerie client Go, C++ o Java per Cloud Bigtable.

Come funzionano i pool di connessione

Un pool di connessioni, noto anche come pool di canali, è una cache di connessioni al database che vengono condivise e riutilizzate per migliorare la latenza e le prestazioni della connessione. Le connessioni vengono utilizzate in un sistema di tipo round robin.

Quando utilizzi Bigtable, crei un singolo client di dati per ogni processo di applicazione. Ogni client ha un pool di connessioni. Ogni pool di connessioni contiene un numero di connessioni gRPC, ciascuna delle quali può gestire fino a 100 stream simultanei. Le richieste inviate tramite queste connessioni passano attraverso il middleware di Google, che le inoltra alla tua tabella. Il livello di middleware è costituito da molte istanze bilanciate in base al carico e ogni richiesta viene indirizzata tramite l'istanza di middleware con la maggiore disponibilità.

Puoi considerare una connessione (o un canale) come un'autostrada con fino a 100 corsie, ciascuna delle quali (stream) può contenere una sola auto (richiesta) in un determinato momento. Il limite di 100 stream simultanei per connessione gRPC viene applicato nel livello middleware di Google e non puoi riconfigurare questo numero.

Una connessione si aggiorna automaticamente una volta ogni ora. Inoltre, se una connessione non ha ricevuto una richiesta in cinque minuti, il middleware la elimina automaticamente e non la ricrea finché non è necessaria un'altra connessione.

Dietro le quinte, ogni canale ha un solo sottocanale. Ogni sottocanale ha una connessione HTTP2 che utilizza TCP per convertire le richieste in byte e inviarle tramite il middleware e poi alla tua tabella. Questo processo viene gestito senza problemi dal servizio Bigtable e non è necessario configurare nulla per realizzarlo.

Pool di connessione e traffico

In che modo i pool di connessione influiscono sulle prestazioni

Idealmente, dovresti disporre di connessioni gRPC sufficienti per gestire le richieste senza buffering. Tuttavia, non devi avere così tante connessioni che vengono interrotte di frequente per mancanza di utilizzo.

Numero di collegamenti insufficiente

Se un pool di connessioni non dispone di connessioni sufficienti per gestire il traffico, il middleware inizia a mettere in coda le richieste e a metterle in buffer. Questo buffering rallenta il traffico, riducendo il numero di richieste al secondo e aumentando la latenza man mano che le richieste aumentano.

Troppe connessioni

Se un pool ha troppe connessioni, ovvero alcune sono inattive, il middleware le disconnette. Quando vengono inviate nuove richieste che richiedono queste autorizzazioni, queste connessioni vengono ristabilite. Ciò significa che, quando il traffico aumenta, le richieste possono non trovare una voce nella cache lato server, causando un lavoro e una latenza aggiuntivi. Se si verifica spesso a causa di livelli di traffico variabili, questa attività può manifestarsi come un picco percepito nella latenza di coda lato client.

Quando modificare le impostazioni predefinite

La dimensione predefinita del pool di connessioni è adatta alla maggior parte delle applicazioni e nella maggior parte dei casi non è necessario modificarla. A seconda della libreria client utilizzata nella tua applicazione, potresti non essere in grado di modificare le dimensioni del pool di connessioni. Il numero di connessioni in ogni pool è configurabile nel codice solo se utilizzi le librerie client Go, C++ o Java per Cloud Bigtable.

Come regola generale, un pool di connessioni ideale ha almeno il doppio del numero di connessioni necessarie per la saturazione massima. Ciò lascia spazio a fluttuazioni del traffico. Ad esempio, se hai 4 connessioni e ognuna gestisce il numero massimo di richieste possibili (100), vuoi ridurre il numero di richieste per connessione a un numero compreso tra 10 e 50, quindi la dimensione ideale del pool di connessioni è almeno il doppio, ovvero un minimo di 8 connessioni.

Gli indicatori che ti consigliano di modificare il numero di connessioni nel pool includono:

Basso throughput combinato con picchi di latenza coda lato client

Se il tuo throughput tipico è piuttosto basso, ad esempio meno di una richiesta al secondo per connessione, e osservi periodicamente una latenza di coda elevata per la tua applicazione, potresti non inviare traffico sufficiente per mantenere attive le connessioni. In questo caso, potrebbe essere necessario ridurre il numero di connessioni nel pool. Consulta la sezione Configurazione dei pool di connessione per scoprire come determinare il numero corretto.

Richieste in buffer

Se noti che le richieste si accumulano lato client, questo potrebbe indicare che stai inviando più richieste in parallelo di quante possa gestire il pool di connessioni. Calcola il numero ottimale, quindi modifica il codice, se necessario.

Per determinare se le richieste si stanno accumulando, puoi utilizzare OpenCensus per esaminare la differenza tra le metriche grpc.io/client/started_rpcs e grpc.io/client/completed_rpcs.

Ambiente virtuale

In alcuni rari casi, il client Bigtable non è in grado di indicare il numero di CPU su cui è in esecuzione l'applicazione e alloca le connessioni come se fosse in uso una sola CPU. Ad esempio, questo può accadere quando utilizzi istanze CPU virtuali in Kubernetes o Docker. In questo caso, devi configurare il numero di pool in base alle linee guida in base al QPS e alla latenza della tua applicazione.

Passaggi successivi