Pool di connessione

Questo argomento descrive il funzionamento dei pool di connessioni in Bigtable, l'impatto che la dimensione del pool di connessioni può avere su un'applicazione che utilizza Bigtable e quando è opportuno modificare le impostazioni predefinite del pool di connessioni.

Dopo aver letto questa pagina, se decidi di modificare la dimensione del pool di connessioni, consulta 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 quando utilizzi le librerie client Go, C++ o Java per Cloud Bigtable.

Come funzionano i pool di connessioni

Un pool di connessioni, noto anche come pool di canali, è una cache di connessioni dei database che vengono condivise e riutilizzate per migliorare la latenza e le prestazioni della connessione. Le connessioni vengono utilizzate in un sistema 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 certo numero di connessioni gRPC, ciascuna in grado di gestire fino a 100 flussi simultanei. Le richieste inviate attraverso queste connessioni passano attraverso il middleware Google, quindi le instrada alla tabella. Il livello middleware è composto da molte istanze con bilanciamento del carico e ogni richiesta viene instradata tramite l'istanza del middleware con la maggiore disponibilità.

Un collegamento (o canale) è come un'autostrada con fino a 100 corsie, dove ogni corsia (flusso) può contenere una sola auto (richiesta) alla volta. Il limite di 100 flussi di dati simultanei per connessione gRPC viene applicato nel livello middleware di Google e non puoi riconfigurare questo numero.

Una connessione si aggiorna automaticamente ogni ora. Inoltre, se una connessione non ha rilevato una richiesta entro cinque minuti, il middleware elimina automaticamente la connessione e la ricrea solo quando è necessaria un'ulteriore connessione.

Dietro le quinte, ogni canale ha un singolo canale secondario. Ogni sottocanale ha una connessione HTTP2 che utilizza il protocollo TCP per convertire le richieste in byte e inviarle tramite il middleware e quindi alla tabella. Questo processo viene gestito senza problemi dal servizio Bigtable e non è necessario configurare niente per farlo.

Impatto dei pool di connessioni sulle prestazioni

Idealmente, dovresti avere un numero sufficiente di connessioni gRPC per gestire le richieste senza buffering. Tuttavia, non dovresti avere un numero così elevato di connessioni da interrompere spesso per insufficienza.

Connessioni insufficienti

Se un pool di connessioni non dispone di connessioni sufficienti per gestire il traffico, il middleware inizia a eseguire il buffering e la coda delle richieste. Questo buffering rallenta il traffico, riducendo il numero di richieste al secondo e aumentando la latenza man mano che le richieste vengono sottoposte a backup.

Troppe connessioni

Se un pool ha troppe connessioni, quindi alcune sono inattive, il middleware scollega le connessioni inattive. Quando arrivano nuove richieste che le richiedono, queste connessioni vengono ripristinate. Ciò significa che, quando il traffico aumenta, le richieste possono riscontrare un fallimento della cache lato server, con conseguente lavoro aggiuntivo e latenza. Se questo accade di frequente a causa di livelli di traffico variabili, questa attività può manifestarsi come un picco percepito nella latenza di coda sul lato client.

Nota: nella maggior parte dei casi non puoi controllare la frequenza di aggiornamento. Tuttavia, se questa latenza di coda è un problema e hai bisogno di una latenza prevedibile a una bassa frequenza di query al secondo (QPS) e utilizzi la libreria client di Cloud Bigtable per Java, puoi configurare le impostazioni di aggiornamento utilizzando la classe BigtableDataSettings.Builder. Se utilizzi la libreria client di Cloud Bigtable per Go, consulta l'esempio di aggiornamento della connessione su GitHub.

Quando modificare le impostazioni predefinite

La dimensione predefinita del pool di connessioni è indicata per la maggior parte delle applicazioni e nella maggior parte dei casi non è necessario modificarla. A seconda della libreria client che utilizzi 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 quando 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 necessario per la massima saturazione. Ciò lascia spazio alle fluttuazioni del traffico. Ad esempio, se hai 4 connessioni e ognuna gestisce il numero massimo di richieste possibile (100), vuoi ridurre il numero di richieste per connessione a un numero compreso tra 10 e 50, in modo che la dimensione ideale del pool di connessioni sia almeno il doppio rispetto a quella minima o almeno 8 connessioni.

Gli indicatori che dovresti prendere in considerazione per modificare il numero di connessioni nel pool includono quanto segue:

Velocità effettiva bassa combinata con picchi di latenza tail lato client

Se la velocità effettiva tipica è piuttosto bassa, ad esempio meno di una richiesta al secondo per connessione, e noti una latenza di coda periodicamente elevata per la tua applicazione, potresti non inviare abbastanza traffico per mantenere attive le connessioni. In questo caso, potrebbe essere necessario ridurre il numero di connessioni nel pool. Consulta Configurazione dei pool di connessioni per scoprire come determinare il numero giusto.

Richieste in buffer

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

Per determinare se le richieste si accumulano, 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. Ciò può accadere, ad esempio, quando utilizzi istanze di CPU virtuali in Kubernetes o Docker. Se questo è evidente, devi configurare il numero di pool in base alle linee guida in base alla latenza e al valore QPS della tua applicazione.

Passaggi successivi

• Scopri come configurare i pool di connessioni.
• Scopri di più sulle prestazioni.