Configuration d'un pool de connexions

Un pooler de connexions est un composant logiciel qui gère les connexions aux bases de données. Cela peut aider de plusieurs manières à améliorer l’utilisation des ressources, à faciliter l’équilibrage de charge ou le basculement et à réduire considérablement les temps de transaction. Dans cet article de blog, nous allons voir ce qu'est un pooler de connexions et comment le configurer.

Un pooler de connexions est un composant logiciel qui gère les connexions à la base de données. Cela peut aider de plusieurs manières à améliorer l’utilisation des ressources, à faciliter l’équilibrage de charge ou le basculement et à réduire considérablement les temps de transaction. Dans cet article de blog, nous allons voir ce qu'est un pooler de connexions et comment le configurer.

Qu'est-ce qu'un pooler de connexions et pourquoi il est utile

L'ouverture d'une connexion à la base de données prend de nombreuses étapes. Nous devons nous connecter au serveur et effectuer la poignée de main initiale, convenir des paramètres de cryptage et de connexion, puis conserver la nouvelle ressource de connexion sur toutes les couches (pilote réseau, couche du système d'exploitation, couche de base de données, etc.). Chaque connexion consomme de la mémoire dont la taille dépend du moteur de base de données. Pour PostgreSQL, cela peut même représenter 1,3 Mo de mémoire pour une connexion. L'ouverture d'une connexion prend également du temps car nous devons négocier les paramètres de la nouvelle connexion.

Si nous continuons à ouvrir une nouvelle connexion pour chaque requête SQL, nous pouvons provoquer plusieurs problèmes pour le serveur de base de données :

• L'ouverture de connexions prend du temps et des ressources, donc nos transactions sont plus lentes

• Nous pouvons dépasser la limite des connexions actives (qui par défaut peut être définie sur quelque chose comme une centaine de connexions)

• La base de données peut consommer plus de mémoire, ce qui peut affecter négativement le taux d'accès au cache et la mémoire libre disponible pour les requêtes

Au lieu d'ouvrir une nouvelle connexion pour chaque requête SQL, on peut mutualiser les connexions. Nous pouvons configurer le pooler de connexions qui conserve le nombre de connexions et les réutilise pour tous les clients. De cette façon, notre application se connecte au pooler au lieu de directement à la base de données, puis le pooler se connecte à la base de données. Cela apporte de multiples avantages :

• Le pooler de connexions maintient les connexions ouvertes beaucoup plus longtemps, ce qui réduit la surcharge liée à l'ouverture et à la fermeture des connexions du côté de la base de données et réduit la latence.

• Nous pouvons obtenir un équilibrage de charge entre les connexions ou même entre les bases de données, ce qui augmente les performances.

• Le pooler peut maintenir un nombre stable de connexions, nous évitons donc le problème d'un trop grand nombre de connexions actives, ce qui réduit l'utilisation des ressources.

• Le pooler peut rediriger les connexions entre les serveurs principal et de secours pour fournir un basculement qui augmente la stabilité et l'évolutivité.

• Le pooler peut stocker le mot de passe de la base de données dans un endroit central, ce qui augmente la sécurité.

• Le pooler peut mettre en cache les résultats pour améliorer les performances des requêtes.

Le pooler de connexions présente également certains inconvénients :

• C'est encore un autre composant de notre système qui peut devenir un point de défaillance.

• La latence du réseau peut augmenter légèrement en raison d'un autre saut de réseau entre l'application et la base de données.

• Un pooler de connexions inefficace peut devenir un goulot d'étranglement.

• Nous devons régler et entretenir le pooler de connexions, ce qui augmente la charge de maintenance.

Différents types de pooling de connexions

Il existe de nombreux façons de mettre en œuvre le regroupement de connexions. Dans cette section, nous examinons divers détails d'implémentation.

Pooler de connexions externes ou internes

Dans un cas typique, nous nous connectons depuis notre application à la base de données. Nous pouvons désormais placer un pool de connexions à l'un des deux endroits suivants : dans l'application elle-même ou quelque part entre l'application et la base de données.

Placer le pool de connexions dans l'application (pooler de connexions côté application) peut être très simple. autant d'ORM ou de pilotes de base de données le prennent en charge dès le départ. Par exemple, JDBC prend en charge cela avec c3p0 et ODBC le prend en charge immédiatement. Cela apporte de nombreux avantages. Nous n'avons pas besoin d'installer et de maintenir des composants supplémentaires car le pooler vit à l'intérieur de l'application. Il suffit de déployer la nouvelle version de l'application et de préparer le pooling. Cela réduit également la latence du réseau, car nous n'avons pas de sauts de réseau supplémentaires (tout vit à l'intérieur de notre application).

Malheureusement, le pooler de connexions côté application présente certains inconvénients. Le plus important est qu’il est configuré pour une seule application. Si nous avons de nombreuses applications (en particulier dans un environnement distribué), nous devons alors configurer le pooler à de nombreux endroits. Sans oublier que nous pouvons encore atteindre la limite du nombre de connexions côté serveur car les poolers ne se connaissent pas. Le fait d'avoir de nombreux poolers de connexions entraîne également une utilisation plus élevée des ressources et est généralement moins performant.

Nous pouvons également utiliser un pooler de connexions externe situé quelque part entre l'application et la base de données. Cela peut fonctionner avec n'importe quel nombre d'applications et nous permet de contrôler avec précision la limite de connexion. Un pooler de connexions centralisé peut également mieux contrôler les ressources et nous permettre de réaliser un basculement ou une répartition de la charge.

Un pooler de connexions externe présente également certains inconvénients. Avant tout, il s’agit d’un autre composant que nous devons installer, configurer, régler et entretenir au fil du temps. Nous devons également reconfigurer chaque application pour utiliser le pooler de connexions (ce qui devrait être aussi simple que de modifier certaines chaînes de connexion et de redéployer l'application). Le pooler externe ajoute également une certaine latence au réseau car il s'agit d'un autre composant réseau entre l'application et la base de données.

Le pooler de connexions externe peut également devenir un point de défaillance. Si le pooler est en panne pour une raison quelconque, les applications ne peuvent plus se connecter à la base de données. Si le pooler est lent ou inefficace, cela affecte toutes les applications qui l'utilisent. Par conséquent, le pooler doit être de haute qualité pour ne pas détériorer les performances globales.

Types de pooling

Chaque pooler doit décider de la manière d'attribuer les connexions aux clients. Il existe généralement trois approches.

La première est le regroupement de sessions. Dans cette approche, la connexion est attribuée au client pour la durée de la session (donc jusqu'à ce que le client se déconnecte ou qu'un délai d'attente soit atteint). Il s'agit de l'approche la plus simple, mais elle limite effectivement le nombre de clients, car chaque client consomme généralement une connexion.

La solution suivante est le regroupement des transactions. Dans cette approche, le pooler attribue la connexion pour chaque transaction et uniquement pour la durée de la transaction. Si un client souhaite exécuter une autre transaction, il doit obtenir une autre connexion (et peut-être devoir attendre qu'une autre connexion soit disponible). Cela permet au pooler de gérer plus de clients et constitue l'approche recommandée.

La dernière approche consiste à attribuer la connexion pour chaque instruction SQL indépendamment. En théorie, cela apporte la plus grande flexibilité et l’utilisation de la connexion. Cependant, cela entraîne qu’une transaction s’étende sur plusieurs connexions. Étant donné que de nombreux paramètres de transaction sont liés à la connexion, cela peut devenir une limitation technique.

Solutions de pooling de connexions

Selon le type de base de données que vous utilisez, il peut y avoir des solutions intégrées, ou vous devrez peut-être les configurer manuellement. Voyons quelques exemples.

Solutions intégrées

En fonction de votre fournisseur d'infrastructure, vous pourrez peut-être utiliser des solutions intégrées ou presque intégrées :

• La base de données Neon PostgreSQL a un PgBouncer intégré

• Supabase a un Supavisor intégré

• Base de données Azure pour PostgreSQL prend en charge PgBouncer intégré

• PostgreSQL de DigitalOcean inclut PgBouncer

• La base de données Azure peut être utilisée avec ProxySql

• La base de données Azure peut être utilisée avec le proxy de base de données Heimdall

• ADO.NET prend en charge un pool de connexions intégré

• Oracle prend en charge le pool de connexions universelles pour JDBC

• Oracle Autonomous Database prend en charge le pool de connexions résidentes de base de données

Solutions externes

Il existe de nombreuses solutions externes que vous pouvez utiliser :

• Proxy Amazon RDS

• Pgpool

• PgBouncer

• odyssée

• Proxy de base de données Heimdall

• ProxySQL

• pgcat

Étude de cas : configuration de PgBouncer

Dans cet exemple, nous allons examiner PgBouncer.

Nous commençons par l'installer comme dans la documentation.

Il faut ensuite le configurer. Les paramètres les plus importants sont :

• pool_mode : Comment gérer les connexions ; nous pouvons utiliser transaction

• max_client_conn : cela configure le nombre de clients pouvant se connecter au pooler de connexions

• default_pool_size : configure le nombre de connexions au serveur autorisées pour chaque base de données utilisateur

• min_pool_size : Combien de connexions de secours à conserver

Après avoir configuré le pooler, nous pouvons vérifier ses performances avec pgbench :

pgbench -c 10 -p -j 2 -t 1000 database_name

PgBouncer peut facilement augmenter le nombre de transactions par seconde de 60 %, comme le montrent les benchmarks :

• Benchmarking des poolers de connexions PostgreSQL : PgBouncer, PgCat et Supavisor

• Améliorez les performances de la base de données grâce au pooling de connexions

• Suralimentez PostgreSQL avec PgBouncer

Résumé

Les poolers de connexions peuvent améliorer les performances et réduire la consommation de ressources. Il existe de nombreuses solutions intégrées que nous pouvons facilement utiliser avec nos bases de données, quel que soit l'endroit où nous les hébergeons et le moteur de base de données avec lequel nous travaillons. Nous devons garder à l’esprit que le pooler de connexions constitue encore un autre point de défaillance et doit être manipulé avec précaution. Un pool de connexions bien configuré peut presque doubler le nombre de transactions par seconde, ce qui améliore considérablement les performances.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!