Pools de connexions

Cet article décrit le fonctionnement des pools de connexions dans Bigtable , l'impact que leur taille peut avoir sur une application qui utilise Bigtable, ainsi que les cas dans lesquels vous pouvez modifier les paramètres par défaut du pool de connexions.

Si vous décidez de modifier la taille de votre pool de connexions après avoir lu cette page, consultez la page Configurer des pools de connexions pour savoir comment déterminer la taille optimale et comment la modifier. Le nombre de connexions dans chaque pool ne peut être configuré dans votre code que lorsque vous utilisez les bibliothèques clientes Go, C++ ou Java pour Cloud Bigtable.

Fonctionnement des pools de connexions

Un pool de connexions, également appelé pool de canaux, est un cache de connexions à la base de données, qui sont partagées et réutilisées pour améliorer la latence et les performances de connexion. Les connexions sont utilisées dans un système round robin.

Lorsque vous utilisez Bigtable, vous créez un seul client de données par processus d'application. Chaque client dispose d'un pool de connexions. Chaque pool de connexions contient un certain nombre de connexions gRPC, qui peuvent chacune gérer jusqu'à 100 flux simultanés. Les requêtes envoyées via ces connexions passent par le middleware Google, qui les achemine ensuite vers votre table. La couche middleware est composée de nombreuses instances à équilibrage de charge, et chaque requête est acheminée via l'instance middleware qui dispose de la plus grande disponibilité.

Vous pouvez considérer une connexion (ou un canal) comme une autoroute comportant jusqu'à 100 voies, chacune d'elles (flux) ne pouvant contenir qu'une seule voiture (requête) à un moment donné. La limite de 100 flux simultanés par connexion gRPC est appliquée dans la couche middleware de Google. Vous ne pouvez pas reconfigurer ce nombre.

Une connexion s'actualise automatiquement une fois par heure. En outre, si une connexion n'a pas reçu de requête pendant cinq minutes, le middleware supprime automatiquement la connexion et ne la recrée pas tant qu'une connexion supplémentaire n'est pas requise.

En arrière-plan, chaque canal possède un seul sous-canal. Chaque sous-canal dispose d'une connexion HTTP2 utilisant TCP pour convertir les requêtes en octets et les envoyer via le middleware jusqu'à votre table. Ce processus est traité de manière fluide par le service Bigtable. Vous n'avez donc aucun paramètre à configurer.

Impact des pools de connexions sur les performances

Idéalement, vous devez disposer de suffisamment de connexions gRPC pour traiter vos requêtes sans mise en mémoire tampon. Cependant, vous ne devez pas en avoir trop, car elles sont régulièrement supprimées si elles ne sont pas suffisamment utilisées.

Connexions insuffisantes

Si un pool de connexions n'a pas assez de connexions pour gérer votre trafic, le middleware commence à effectuer la mise en mémoire tampon et à placer les requêtes en file d'attente. Cette mise en mémoire tampon ralentit le trafic, ce qui réduit le nombre de requêtes par seconde et augmente la latence à mesure que les requêtes sont sauvegardées.

Trop de connexions

Si un pool possède trop de connexions, c'est-à-dire que certaines connexions sont inactives, le middleware déconnecte les connexions inactives. Ensuite, lorsque de nouvelles requêtes les requièrent, ces connexions sont rétablies. Cela signifie que lorsque le trafic augmente, les requêtes peuvent rencontrer un défaut de cache côté serveur, ce qui entraîne des tâches supplémentaires et de la latence. Si cette situation se produit fréquemment en raison de divers niveaux de trafic, cette activité peut se traduire par un pic perçu dans la latence de queue côté client.

Remarque : Dans la plupart des cas, vous ne pouvez pas contrôler la fréquence d'actualisation. Toutefois, si cette latence de queue pose problème et que vous avez besoin d'une latence prévisible pour un faible taux de requêtes par seconde (RPS), et que vous utilisez la bibliothèque cliente Cloud Bigtable pour Java, vous pouvez configurer les paramètres d'actualisation à l'aide de la classe BigtableDataSettings.Builder. Si vous utilisez la bibliothèque cliente Cloud Bigtable pour Go, consultez l'exemple d'actualisation de connexion sur GitHub.

Modifier les paramètres par défaut

La taille du pool de connexions par défaut convient à la majorité des applications. Dans la plupart des cas, il n'est donc pas nécessaire de la modifier. Selon la bibliothèque cliente utilisée dans votre application, vous ne pourrez peut-être pas modifier la taille de votre pool de connexions. Le nombre de connexions dans chaque pool ne peut être configuré dans votre code que lorsque vous utilisez les bibliothèques clientes Go, C++ ou Java pour Cloud Bigtable.

En règle générale, un pool de connexions idéal a au moins deux fois plus de connexions qu'il n'en faut pour une saturation maximale. Cela permet de faire face aux fluctuations du trafic. Par exemple, si vous disposez de quatre connexions et que chacune traite le nombre maximal de requêtes possible (100), vous pouvez réduire le nombre de requêtes par connexion à un nombre compris entre 10 et 50. La taille idéale du pool de connexions est au moins deux fois supérieure ou égale à 8 connexions au minimum.

Vous devez envisager de modifier le nombre de connexions dans le pool lorsque vous recevez les signaux suivants :

Faible débit associé à des pics de latence de queue côté client

Si votre débit type est relativement faible, par exemple moins d'une requête par seconde et par connexion, et que vous constatez que la latence de votre application est régulièrement élevée, vous risquez de ne pas envoyer suffisamment de trafic pour maintenir les connexions. Dans ce cas, vous devrez peut-être réduire le nombre de connexions dans le pool. Pour savoir comment déterminer le nombre approprié, consultez la page Configurer des pools de connexions.

Requêtes mises en mémoire tampon

Si vous constatez que les requêtes s'accumulent côté client, cela peut indiquer que vous envoyez plus de requêtes simultanées que ce que le pool de connexions peut gérer. Calculez le nombre optimal, puis modifiez votre code si nécessaire.

Pour déterminer si les requêtes s'accumulent, vous pouvez utiliser OpenCensus ain d'examiner la différence entre les métriques grpc.io/client/started_rpcs et grpc.io/client/completed_rpcs.

Environnement virtuel

Dans de rares cas, le client Bigtable ne peut pas indiquer le nombre de processeurs sur lesquels l'application s'exécute, et alloue des connexions comme si un seul processeur était utilisé. Cela peut arriver par exemple lorsque vous utilisez des instances de processeurs virtuels dans Kubernetes ou Docker. Si c'est le cas, vous devez configurer le nombre de pools en suivant les consignes basées sur le RPS et la latence de votre application.

Étape suivante

• Apprenez à configurer des pools de connexions.
• Obtenez plus d'informations sur les performances.