Décision : comment mettre en place le pooling de connexions ?
Chaque connexion à la base a un coût en mémoire et en ordonnancement ; une croissance incontrôlée du nombre de connexions ralentit le serveur, voire le fait tomber. Un pool de connexions résout ce problème en réutilisant un petit nombre de connexions persistantes. Cet arbre guide les décisions sur l'emplacement du pool, le mode à utiliser (session/transaction/statement) et la bonne taille, et souligne pourquoi un pooler externe est obligatoire dans les environnements serverless.
Comment votre architecture applicative se connecte-t-elle ?
La décision de pooling commence par l'architecture. S'agit-il d'un seul processus applicatif de longue durée (serveur classique), de nombreux processus/instances indépendants (microservices, nombreux pods), ou de fonctions serverless/Lambda qui naissent et meurent à chaque requête ? Chaque cas exige un placement de pool différent.
- Un/quelques processus applicatifs de longue durée
- De nombreux processus/instances/pods se connectent à la même base
- Serverless / Lambda / fonctions de courte durée
- Montrez-moi d'abord comment choisir la bonne taille de pool
Comment choisir le mode du pooler intermédiaire ?
Avec de nombreux clients, un pooler intermédiaire (PgBouncer, ProxySQL) maintient un faible nombre de connexions sur la base. Mais le mode de pool dépend des fonctionnalités utilisées par l'application : dépendez-vous d'un état lié à la session (prepared statements, tables temporaires, SET, advisory locks, fonctionnalités de niveau session), ou tout se termine-t-il au sein d'une seule transaction ?
- Je dépends de l'état de session (SET, tables temporaires, prepared statements de session)
- Les transactions sont courtes et indépendantes ; je ne conserve aucun état de session
Recommandation : pool de connexions dans l'application
Pour un ou quelques processus de longue durée, une bibliothèque de pool intégrée à l'application (HikariCP, le pool intégré de database/sql en Go, le connection pooling de .NET) couvre la plupart des besoins. Les connexions sont ouvertes une fois et réutilisées sans cesse.
Recommandation : dimensionnez correctement le pool
Le pool ne doit être ni trop petit (les requêtes attendent) ni trop grand. Trop de connexions provoquent des changements de contexte CPU et une contention de verrous, et réduisent le débit. La taille n'est pas un nombre à augmenter indéfiniment, mais un petit nombre fondé sur les cœurs et les E/S.
Recommandation : mode de pool session
En mode session, une connexion client est liée à une connexion serveur jusqu'à la fin de sa session. L'état de niveau session (SET, tables temporaires, advisory locks, prepared statements de session) est préservé, mais le partage des connexions est minimal.
Recommandation : mode de pool transaction
En mode transaction, une connexion serveur n'est prêtée au client que pendant la durée d'une transaction et retourne au pool à la fin de celle-ci. Ainsi, des milliers de clients peuvent travailler avec très peu de connexions réelles sur la base ; c'est le mode le plus courant à grande échelle.
Recommandation : un pooler externe est obligatoire en serverless
Les fonctions serverless/Lambda montent en charge rapidement et chaque instance ouvre sa propre connexion ; un pool dans l'application n'aide pas ici car les instances sont de courte durée et ne partagent rien. Lorsque des centaines/milliers d'instances apparaissent soudainement, la limite de connexions de la base est dépassée. La solution est un pool de connexions externe placé devant la base.