Configurer des pools de connexions
Certaines bibliothèques clientes Cloud Bigtable vous permettent de configurer le nombre de canaux gRPC dans le pool de connexions d'un client, également appelé "pool de canaux". Dans la plupart des cas, la configuration par défaut est correcte. Il n'est donc pas nécessaire de la modifier.
Les pools de connexions sont automatiquement redimensionnés si nécessaire lorsque vous utilisez la bibliothèque cliente Cloud Bigtable pour Java version 2.23.0 ou ultérieure, et lorsque vous utilisez le client Cloud Bigtable HBase pour Java version 2.9.1 ou ultérieure.
Cette page explique comment déterminer la taille optimale du pool de connexions de votre application. Elle présente des extraits de code qui montrent comment configurer les pools de connexions.
Avant de lire cette page, consultez la présentation des pools de connexions Bigtable pour savoir comment ils fonctionnent et si vous devez modifier les vôtres.
Les bibliothèques clientes suivantes permettent de regrouper les connexions et de configurer le nombre de pools :
- Bibliothèque cliente Go pour Cloud Bigtable
- Bibliothèque cliente Cloud Bigtable HBase pour Java
- Bibliothèque cliente Cloud Bigtable pour Java
- Bibliothèque cliente Cloud Bigtable pour C++
Déterminer la taille appropriée des pools de connexions
Dans l'idéal, pour faire face aux fluctuations de trafic, un pool de connexions a environ deux fois plus de connexions qu'il n'en faut pour une saturation maximale. Étant donné qu'une connexion peut gérer jusqu'à 100 requêtes simultanées, il est optimal d'avoir environ entre 10 et 50 requêtes en attente par connexion. Ce concept est décrit plus en détail sur la page Pools de connexions.
Surveillez le trafic après avoir apporté des modifications et ajustez le nombre de connexions dans votre pool si nécessaire.
La procédure suivante vous aide à calculer le nombre optimal de connexions dans votre pool de canaux à l'aide de métriques côté client, telles que celles disponibles dans OpenCensus.
- À l'aide des métriques côté client, collectez les informations suivantes :
- Nombre maximal de requêtes par seconde (RPS) par client lorsque votre application exécute une charge de travail type.
- Latence moyenne (temps de réponse d'une seule requête) en ms.
- Déterminez le nombre de requêtes que vous pouvez envoyer en série par seconde en divisant 1 000 par la valeur de latence moyenne.
- Divisez le RPS en secondes par le nombre de requêtes en série par seconde.
- Divisez le résultat par 50 requêtes par canal pour déterminer la taille minimale optimale du pool de canaux. (Si votre calcul est inférieur à 2, utilisez au moins deux canaux pour assurer la redondance.)
- Divisez le même résultat par 10 requêtes par canal pour déterminer la taille maximale optimale du pool de canaux.
Ces étapes sont exprimées dans les équations suivantes :
(RPS en secondes ÷ (1 000 ÷ latence en ms)) ÷ 50 flux = nombre minimal de connexions optimal
(RPS en secondes ÷ (1 000 ÷ latence en ms)) ÷ 10 flux = nombre maximal de connexions optimal
Exemple
Votre application envoie généralement 50 000 requêtes par seconde et la latence moyenne est de 10 ms. Divisez 1 000 par 10 ms pour déterminer si vous pouvez envoyer 100 requêtes en série par seconde. Divisez ce nombre par 50 000 pour obtenir le parallélisme nécessaire pour envoyer 50 000 RPS : 500. Chaque canal peut envoyer au maximum 100 requêtes simultanément, et votre utilisation du canal cible est comprise entre 10 et 50 flux simultanés. Par conséquent, pour calculer le minimum, divisez 500 par 50 pour obtenir 10. Pour trouver le maximum, divisez 500 par 10 pour obtenir 50. Cela signifie que la taille du pool de canaux pour cet exemple doit être comprise entre 10 et 50 connexions.
Définir la taille du pool
Les exemples de code suivants montrent comment configurer le nombre de pools dans les bibliothèques clientes qui vous permettent de définir la taille du pool.
Go
HBase
Cet exemple ne s'applique qu'aux versions de la bibliothèque cliente antérieures à la version 2.9.1, lorsque le redimensionnement automatique a été introduit.
Java
Cet exemple ne s'applique qu'aux versions de la bibliothèque cliente antérieures à la version 2.23.0, lorsque le redimensionnement automatique a été introduit.