⚡️ Connection Pooling : L'atout des bases de données à haute performance

date

Dec 29, 2024

slug

ameliorer-performances-reduire-charge-bases-donnees-pooler-connexion

author

status

Public

tags

Network

Optimisation

Database

summary

Établir une connexion avec la base de données, c’est mettre en place un canal de communication direct entre l’application cliente et le serveur. Ce canal prend en charge le transfert des données, l’exécution des requêtes, ainsi que l’initialisation des transactions. Une fois la connexion établie, l’application cliente peut envoyer ses commandes et recevoir les réponses du serveur. Cependant, créer une nouvelle connexion à chaque opération peut rapidement générer des problèmes de performances, en particulier pour les applications stratégiques.

type

Post

thumbnail

category

🤖 Computer Science

updatedAt

Dec 29, 2025 03:00 AM

 FATAL:  no more connections allowed (max_client_conn)

Le pooling de connexions permet de réutiliser des connexions existantes à une base de données au lieu d'en créer de nouvelles à chaque demande. Cela réduit le temps nécessaire pour établir des connexions et améliore les performances globales d’access a la base de donnee.

Résultat : les invités (les requêtes) entrent plus rapidement et plus facilement, et la salle (la base de données) n’est pas submergée.

Integration avec pgbouncer

👉🏼 Fonctionnalités Clés :

• Modes de pooling : session, transaction, statement.

• Faible utilisation de la mémoire.

• Supporte différentes méthodes d'authentification.

• Gestion efficace des connexions persistantes.

Exemple d'Intégration avec compose

services:
  postgres:
    image: postgres:14
    environment:
      POSTGRES_USER: user
      POSTGRES_PASSWORD: password
      POSTGRES_DB: mydb
    ports:
      - "5432:5432"
    volumes:
      - pgdata:/var/lib/postgresql/data

  pgbouncer:
    image: edoburu/pgbouncer
    environment:
      DB_HOST: postgres
      DB_PORT: 5432
      DB_USER: user
      DB_PASSWORD: password
      DB_NAME: mydb
      POOL_MODE: transaction
      MAX_CLIENT_CONN: 100
      DEFAULT_POOL_SIZE: 20
    ports:
      - "6432:6432"
    depends_on:
      - postgres

volumes:
  pgdata:

• POOL_MODE: Le mode de pooling utilisé par PgBouncer. Les options incluent :
• session : Une connexion est attribuée à un client pour toute la durée de la session.
• transaction : Une connexion est attribuée à un client pour la durée d'une transaction.
• statement : Une connexion est attribuée pour chaque requête individuelle.
Dans cet exemple, transaction est utilisé pour un bon équilibre entre performance et isolation des transactions.

• MAX_CLIENT_CONN: Le nombre maximum de connexions clients que PgBouncer peut accepter. Ici, il est fixé à 100.

• DEFAULT_POOL_SIZE: Le nombre maximum de connexions que PgBouncer peut ouvrir vers PostgreSQL par pool. Dans cet exemple, 20 connexions sont ouvertes par pool.

Comparaison des Gestionnaires de Pool de Connexions

Benchmark

Observations Clés :

1. Performance Globale
• PgBouncer améliore les performances dans tous les scénarios de charge
• L'amélioration est plus marquée sur les charges légères et moyennes

2. Stabilité
• Réduction significative des temps maximums, surtout sous charge élevée
• PgBouncer réduit la variance des temps de réponse

3. Charge Élevée
• Sous forte charge (5000 requêtes), PgBouncer :
• Réduit les pics de latence de 52%
• Maintient un temps moyen plus stable
• Présente un temps minimum légèrement plus élevé

4. Fiabilité
• Aucune requête échouée dans tous les scénarios
• 100% de taux de succès avec et sans PgBouncer

👉🏼 Point important

L'analyse des résultats de ce benchmark démontre clairement les avantages d'utiliser PgBouncer pour la gestion des connexions PostgreSQL. Cependant, il est essentiel de noter que ces résultats sont obtenus dans un environnement contrôlé avec des paramètres spécifiques. En situation réelle, chaque cas d'utilisation présente des caractéristiques uniques qui nécessitent une approche personnalisée.

1. Configuration de PgBouncer
• Le mode de pool (transaction, session, statement) doit être choisi en fonction du comportement de l'application
• La taille du pool et le nombre maximal de connexions doivent être ajustés selon les ressources disponibles et les patterns d'utilisation
• Le monitoring actif est nécessaire pour affiner ces paramètres dans le temps

2. Facteurs d'influence
• La nature des requêtes réelles peut être très différente du test (complexité, durée, fréquence)
• La charge mémoire et CPU doit être surveillée pour éviter la surallocation
• Le réseau et la latence peuvent impacter significativement les performances

3. Recommandations pratiques
• Commencer avec des paramètres conservateurs et les ajuster progressivement
• Mettre en place une surveillance continue des métriques clés (temps de réponse, nombre de connexions, taux d'erreur)
• Effectuer des tests représentatifs de la charge réelle de production
• Prévoir des marges pour les pics de charge imprévus
 

Ressources Supplémentaires

• https://www.ibm.com/docs/fr/was-nd/8.5.5?topic=architecture-connection-pooling

• https://tembo.io/blog/postgres-connection-poolers