Dans nos articles précédents de cette série, nous avons longuement parlé de l'utilisation de PgBouncer et Pgpool-II, de l'architecture du pool de connexions et des avantages et inconvénients d'en tirer parti pour votre déploiement PostgreSQL. Dans notre dernier article, nous les placerons en tête-à-tête dans une comparaison détaillée des fonctionnalités et comparerons les résultats des performances de PgBouncer par rapport à Pgpool-II pour votre hébergement PostgreSQL !
Comment les fonctionnalités s'empilent-elles ?
Commençons par comparer les fonctionnalités de PgBouncer à celles de Pgpool-II :
PgBouncer | Pgpool-II | |
|---|---|---|
| Consommation de ressources | Il utilise un seul processus ce qui le rend très léger. PgBouncer garantit une faible empreinte mémoire, même lorsqu'il s'agit de grands ensembles de données. Gagnant ! | Si nous avons besoin de N connexions parallèles, cela bifurque N processus enfants. Par défaut, 32 processus enfants sont dupliqués. |
| Quand les connexions sont-elles réutilisées ? | PgBouncer définit un pool par combinaison utilisateur + base de données. Ceci est partagé entre tous les clients, donc une connexion groupée est disponible pour tous les clients. Gagnant ! | Pgpool-II définit un processus par processus enfant. Nous ne pouvons pas contrôler à quel processus enfant un client se connecte. Un client ne bénéficie d'une connexion groupée que s'il se connecte à un enfant qui a déjà servi une connexion pour cette combinaison base de données + utilisateur. |
| Modes de regroupement | PgBouncer prend en charge trois modes différents :session (la connexion est renvoyée au pool lorsque le client se déconnecte), transaction (renvoyée au pool lorsque le client s'engage ou annule) ou instruction ( connexion retournée au pool après l'exécution de chaque instruction). Gagnant ! | Pgpool-II ne prend en charge que le mode de regroupement de sessions - l'efficacité du regroupement dépend du bon comportement des clients. |
| Haute disponibilité | Non pris en charge. | La haute disponibilité PostgreSQL est prise en charge via les processus d'observation intégrés Pgpool-II. Gagnant ! |
| Équilibrage de charge | Non pris en charge - PgBouncer recommande l'utilisation de HAProxy pour la haute disponibilité et l'équilibrage de charge. | Prend en charge l'équilibrage de charge automatique - est même assez intelligent pour rediriger les demandes de lecture vers les veilles et les écritures vers les maîtres. Gagnant ! |
| Prise en charge de plusieurs clusters | Une instance de PgBouncer peut faire face à plusieurs clusters PostgreSQL (un nœud ou des jeux de répliques). Cela peut réduire le coût du middleware lors de l'utilisation de plusieurs clusters PostgreSQL. Gagnant ! (Remarque :cet avantage ne concerne que des scénarios spécifiques) | Pgpool-II ne prend pas en charge plusieurs clusters. |
| Contrôle de connexion | PgBouncer permet de limiter les connexions par pool, par base de données, par utilisateur ou par client. Gagnant ! | Pgpool-II permet de limiter uniquement le nombre total de connexions. |
| File d'attente de connexion | PgBouncer prend en charge la mise en file d'attente au niveau de l'application (c'est-à-dire que PgBouncer maintient la file d'attente). Gagnant ! | Pgpool-II prend en charge la mise en file d'attente au niveau du noyau, ce qui peut entraîner le blocage de pg_bench sur CentOS 6. |
| Authentification | L'authentification directe est prise en charge via PgBouncer. Gagnant ! | Pgpool-II ne prend pas en charge l'authentification unique :les utilisateurs et leurs mots de passe cryptés md5 doivent être répertoriés dans un fichier et mis à jour manuellement chaque fois qu'un utilisateur met à jour leur mot de passe. Pgpool-II prend en charge l'authentification sans mot de passe via des certificats PAM ou SSL. Cependant, ceux-ci doivent être configurés en dehors du système PostgreSQL, tandis que PgBouncer peut décharger cela sur le serveur PostgreSQL. |
| Administration | PgBouncer fournit une base de données virtuelle qui rapporte diverses statistiques utiles. | Pgpool-II fournit une interface d'administration détaillée, y compris une interface graphique. Gagnant ! |
| Authentification basée sur l'hôte | Pris en charge. À égalité ! | Pris en charge. À égalité ! |
| Support SSL | Prise en charge complète. À égalité ! | Prise en charge complète. À égalité ! |
| Réplication logique | Non pris en charge par PgBouncer. À égalité ! | Pris en charge via Pgpool-II, mais cela se fait en envoyant les requêtes d'écriture à tous les nœuds, et n'est généralement pas recommandé. À égalité ! |
| Licence | ISC :très permissif, autorise pratiquement toutes les utilisations. À égalité ! | Licence personnalisée – tout aussi permissive. À égalité ! |
L'essentiel :Pgpool-II est un excellent outil si vous avez besoin d'un équilibrage de charge et d'une haute disponibilité. La mise en commun des connexions est presque un bonus que vous obtenez. PgBouncer ne fait qu'une chose, mais le fait vraiment bien. Si l'objectif est de limiter le nombre de connexions et de réduire la consommation de ressources, PgBouncer gagne haut la main.
Tests de performances
Bien que PgBouncer puisse sembler être la meilleure option en théorie, la théorie peut souvent être trompeuse. Nous avons donc opposé les deux pooleurs de connexions en tête-à-tête, à l'aide de l'outil standard pgbench, pour voir lequel fournit le meilleur débit de transactions par seconde grâce à un test de référence. Pour faire bonne mesure, nous avons également effectué les mêmes tests sans pooler de connexion.
Conditions de test
Tous les tests de performances de PostgreSQL ont été exécutés dans les conditions suivantes :
- Pgbench initialisé avec un facteur d'échelle de 100.
- Désactivation du vide automatique sur l'instance PostgreSQL pour éviter les interférences.
- Aucune autre charge de travail ne fonctionnait à ce moment-là.
- Utilisé le script pgbench par défaut pour exécuter les tests.
- Utilisation des paramètres par défaut pour PgBouncer et Pgpool-II, sauf max_children *. Toutes les limites de PostgreSQL ont également été définies sur leurs valeurs par défaut.
- Tous les tests ont été exécutés en tant que thread unique, sur une machine à processeur unique et à 2 cœurs, pendant une durée de 5 minutes.
- Forcé pgbench à créer une nouvelle connexion pour chaque transaction en utilisant l'option -C. Cela émule les charges de travail des applications Web modernes et c'est la seule raison d'utiliser un pooler !
Nous avons exécuté chaque itération pendant 5 minutes pour nous assurer que tout bruit était moyenné. Voici comment le middleware a été installé :
- Pour PgBouncer, nous l'avons installé sur la même machine que le(s) serveur(s) PostgreSQL. Il s'agit de la configuration que nous utilisons dans nos clusters PostgreSQL gérés. Étant donné que PgBouncer est un processus très léger, son installation sur la boîte n'a aucun impact sur les performances globales.
- Pour Pgpool-II, nous avons testé à la fois lorsque l'instance Pgpool-II était installée sur la même machine que PostgreSQL (sur la colonne de la boîte) et lorsqu'elle était installée sur une machine différente (hors colonne de case). Comme prévu, les performances sont bien meilleures lorsque Pgpool-II est prêt à l'emploi, car il n'a pas à rivaliser avec le serveur PostgreSQL pour les ressources.
Référence de débit
Voici les résultats des transactions par seconde (TPS) pour chaque scénario sur une plage de nombre de clients :
| Nombre de clients | Sans regroupement | PgBouncer | Pgpool-II (sur la boîte) | Pgpool-II (hors boîte) |
|---|---|---|---|---|
| 10 | 16,96 | 26,86 | 15,52 | 18.22 |
| 20 | 16,97 | 27.19 | 15,67 | 18,28 |
| 40 | 16,73 | 26,77 | 15,33 | 18,3 |
| 80 | 16,75 | 26,64 | 15,53 | 18.13 |
| 100 | 16,51 | 26,73 | 15,66 | 18,45 |
| 200 | Connexions interrompues. | 26,93 | Connexions interrompues lorsque max-children> 200, pgbench se bloque à la valeur max-children si <=100. | Connexions interrompues lorsque max-children> 200, pgbench se bloque à la valeur max-children si <=100. |
Pgpool-II se bloque lorsque pg_bench est exécuté avec plus de clients que max_children. Nous avons donc augmenté le max_children pour qu'il corresponde au nombre de clients pour chaque test.
Si nous calculons le pourcentage d'augmentation du TPS lors de l'utilisation d'un pool de connexions, voici ce que nous obtenons :
| Nombre de clients | PgBouncer | Pgpool-II (sur la boîte) | Pgpool-II (hors boîte) |
|---|---|---|---|
| 10 | 58,37 % | -8,49 % | 7,43 % |
| 20 | 60,22 % | -7,66 % | 7,72 % |
| 40 | 60,01 % | -8,37 % | 9,38 % |
| 80 | 59,04 % | -7,28 % | 8,24 % |
| 100 | 61,90 % | -5,15 % | 11,75 % |
* Algorithme d'amélioration =(avec pooler – sans)/sans
Derniers mots
Comme vous pouvez le voir dans les résultats des tests de performances, une connexion bien configurée et un pooler de connexions bien adapté peuvent augmenter considérablement le débit des transactions, même avec un nombre assez restreint de clients. Les poolers de connexions sont particulièrement utiles pour leur prise en charge de la mise en file d'attente - lorsque le nombre de clients dépasse le nombre maximal de clients pris en charge par le serveur PostgreSQL, PgBouncer est toujours en mesure de maintenir le taux de transaction, tandis que les connexions directes à PostgreSQL sont interrompues.
Cependant, un pooler de connexion mal configuré peut en fait réduire les performances que nous avons vues avec la configuration Pgpool-II ici. Une partie du problème est que l'utilisation de Pgpool-II double le nombre de processus exécutés sur le même serveur - nous devons exécutez Pgpool-II sur un serveur séparé pour obtenir de bonnes performances. Mais même dans ce cas, PgBouncer parvient à fournir de meilleures performances pour ce nombre relativement restreint de clients.
Notez également que le test ici a été parfaitement conçu pour Pgpool-II - puisque lorsque N> 32, le nombre de clients et le nombre de processus enfants étaient les mêmes, et donc, chaque reconnexion était garantie de trouver un processus en cache. Même alors, PgBouncer était l'alternative la plus rapide.
Ainsi, nos tests indiquent que PgBouncer est le bien meilleur choix pour le regroupement de connexions. Mais, il est important de se rappeler que même si un pooler de connexions est absolument obligatoire pour la plupart des charges de travail réalistes, que vous gagniez plus en utilisant un pool côté client ou un middleware tel que PgBouncer dépend de votre application. Les modèles d'accès aux données joueraient un rôle, tout comme les latences impliquées en fonction de votre architecture. Nous vous recommandons de tester votre charge de travail par rapport aux deux, puis de décider de la meilleure marche à suivre :il n'y a pas de meilleure alternative à l'expérimentation !
