Beaucoup m'ont demandé dans quelles conditions ils devraient utiliser PgBouncer avec Odoo, et d'autres veulent savoir si des configurations spécifiques doivent être mises en place pour garantir des performances améliorées.

J'ai donc décidé d'utiliser cet article pour répondre à ces questions et expliquer la configuration entre Odoo et PgBouncer un peu plus en détail que je ne l'ai fait dans mon article précédent , où j'ai discuté de la gestion des gros volumes de données dans Odoo.

Ici, je vais expliquer ce qu'est PgBouncer, quand et pourquoi vous devriez l'utiliser dans la mise en œuvre d'Odoo, les recommandations des paramètres d'optimisation des performances et mes mises en garde.

Allons-y.

Table des matières

Qu'est-ce que PgBouncer ?
Pourquoi devriez-vous utiliser PgBouncer ?
Quand utiliser PgBouncer dans les mises en œuvre d'Odoo ?
Cas d'utilisation typiques de PgBouncer avec Odoo
Quel est le gain de performance attendu avec PgBouncer ?
Recommandations initiales pour une configuration orientée performances d'Odoo
Comprendre les paramètres et ajuster les performances en conséquence
Compréhension des principaux paramètres de PgBouncer
Cohérence entre les systèmes
Utiliser avec prudence

Qu'est-ce que PgBouncer?

PgBouncer est un pool de connexions léger pour les bases de données PostgreSQL. Son objectif principal est d'améliorer les performances et la scalabilité des serveurs de bases de données en gérant un pool de connexions client vers la base de données.

Lorsqu'une application demande une connexion à la base de données, au lieu d'établir une nouvelle connexion au serveur à chaque fois, PgBouncer crée une nouvelle connexion ou réutilise une connexion existante de son pool.

Cela réduit les frais généraux liés à l'établissement de nouvelles connexions et peut aider à résoudre les problèmes de performances sur le serveur de bases de données causés par de nombreuses connexions simultanées.

De plus, PgBouncer peut être configuré pour effectuer une répartition de charge sur plusieurs serveurs de bases de données afin d'améliorer les performances et la scalabilité globales du système.

Pourquoi devriez-vous utiliser PgBouncer?

Je recommande d'utiliser un pooler tel que PgBouncer pour les raisons suivantes:

• Odoo utilise des connexions persistantes, ce qui a tendance à encombrer le connecteur en ouvrant parfois plus de connexions que le nombre réel autorisé par le cluster.
• Les connexions inutiles d'Odoo restant dans l'état SLEEP bloquent et verrouillent d'importantes quantités de mémoire (voir les colonnes STATE et RES dans pg_activity, par exemple).
• Le manque de mémoire PostgreSQL affecte gravement la base de données et les performances globales du système Odoo tout en obligeant le cluster de bases de données à recourir à SWAP lorsque des tâches inactives piègent la mémoire physique en direct.

L'utilisation de PgBouncer avec la mise en œuvre d'Odoo garantit une excellente gestion de la mémoire, une meilleure connexion et un temps de réponse amélioré d'Odoo grâce à un ratio TPS / seconde plus élevé sous des charges lourdes avec de nombreux utilisateurs.

Quand devez-vous appliquer la solution PgBouncer-Odoo ?

En général, vous ne devriez utiliser PgBouncer avec Odoo que dans les circonstances suivantes :

• Vous avez de nombreux utilisateurs ou bases de données simultanés sur le même cluster de BD.
• Vous manquez toujours de mémoire dans votre cluster de bases de données, ce qui met une pression sur votre stockage I/O.
• Les performances de votre cluster de bases de données PostgreSQL sont insatisfaisantes en cas d'utilisation simultanée intensive.

Cas d'utilisation typiques de PgBouncer avec Odoo

Votre déploiement PgBouncer-Odoo doit relever l'une de ces catégories :

1. Un grand nombre d'utilisateurs simultanés d'Odoo.
2. Un grand nombre de connexions PostgreSQL ouvertes.
3. Une architecture Odoo distribuée impliquant une instance/conteneur VM extensible Odoo faisant face à un cluster de bases de données unique et non extensible.
4. Une architecture complexe impliquant différentes routes d'accès direct et requêtes à la base de données Odoo mais non gérée par Odoo (accès direct à PostgreSQL à la place).

Quel est le gain de performance attendu avec PgBouncer ?

Voici un graphique illustrant la performance d'un cluster en termes de TPS lorsqu'il est soumis à un plus grand nombre de demandes simultanées :

Source: Percona

Ces données sont assez fiables. Nos derniers tests de performance exécutés avec la version 1.17.0 de PgBouncer ainsi qu'avec Odoo 16 Enterprise et PostgreSQL 14 donnent des résultats très similaires. Comme prévu, Pg-bouncer permet d'obtenir de meilleures performances lorsque le nombre de threads/clients concurrents commence à augmenter.

Dans le cas d'Odoo, les gains de performance commencent à partir d'environ 25 utilisateurs intensifs et plus, en fonction des critères suivants:

Sujet	Levier	Description
Utilisateurs	ÉLEVÉ	Plus le nombre d'utilisateurs augmente, plus le volume de requêtes concurrentes augmente. En raison de la tendance de l'ORM Odoo à générer un nombre important de requêtes, même pour de petites actions de l'utilisateur, une grande base d'utilisateurs entraînera un volume substantiel de requêtes SQL.
Complexité	MOYENNE	Les requêtes très complexes ont tendance à lancer des sous-requêtes, à initier des requêtes parallèles et à ouvrir de nouvelles connexions.
Activité/tarif de l'utilisateur	ÉLEVÉ	Un utilisateur actif effectuant de nombreuses actions sur Odoo ouvrira plus de connexions et générera plus de requêtes.

Recommandations initiales pour une configuration orientée performances d'Odoo

Si vous souhaitez optimiser les performances d'Odoo avec PgBouncer, je vous conseille de suivre ces bonnes pratiques :

1. Source : Compilez votre source et créez votre propre service. Contrôler les entrées et sorties donnera un résultat bien meilleur que de simplement faire 'apt-get install'.
2. Emplacement de l'instance de déploiement : N'installez pas PgBouncer sur une instance différente du cluster, sauf si ce cluster n'est pas accessible au niveau système (exemple : GCP CLOUD SQL, AWS RDS, etc.). Ce faisant, cela dégraderait le temps d'accès de l'instance Odoo au cluster PostgreSQL en insérant quatre latences réseau entre eux :

a. 1 latence de la machine Odoo à PgBouncer.

b. 1 latence de PgBouncer à PostgreSQL.

c. Les deux autres sur le chemin du retour de PostgreSQL à Odoo.

• Stratégie de mise en pool : Utilisez uniquement la mise en pool transactionnelle. Tout autre mode entrera en conflit avec le long-polling d'Odoo ou rendra l'utilisation de PgBouncer inutile.
• Authentification: Essayez d'utiliser TRUST auth_type: Cela supprimera la surcharge de l'étape AUTH de PostgreSQL en contournant la plupart du mécanisme pg_hba. Pendant ce temps, les informations d'identification de l'utilisateur pour l'utilisateur Odoo seront stockées en mémoire et permettront un accès direct d'Odoo au cluster PostgreSQL.
• Port d'écoute: Laissez uniquement PgBouncer écouter sur localhost (127.0.0.1); sinon, vous générez un risque de sécurité très élevé. Si vous devez déployer PgBouncer en dehors du service PostgreSQL, assurez-vous de contrôler les adresses IP à partir desquelles vous écoutez.

Vous souhaitez améliorer la gestion de la mémoire et le temps de réponse dans Odoo?

Laissez-nous vous aider

Comprendre les paramètres et ajuster les performances en conséquence

Remarque: PgBouncer est un excellent outil lorsqu'il est finement réglé et que les paramètres sont correctement configurés. Tout déploiement par défaut sans ratios et valeurs précisément calculés finira par rendre les performances et la situation initiales bien pires et peut potentiellement entraîner une défaillance du service.

Comprendre les principaux paramètres de PgBouncer

À partir du fichier pgbouncer.ini initial, nous nous concentrerons sur les principales notions détaillées ci-dessous:

a. Délai de vérification du serveur

server_check_delay ⇒ Combien de temps conserver les connexions libérées disponibles pour une réutilisation immédiate, sans exécuter de requêtes de vérification de la cohérence. Si 0, alors la requête est toujours exécutée.

Cela définit à quel point vous souhaitez que votre pooler ferme rapidement une connexion inactive et récupère les ressources du cluster PostgreSQL:

• Si vous mettez 30 , PgBouncer attendra 30 secondes après que le résultat de l'instruction Odoo a été donné avant de fermer la connexion.
• Si vous mettez 0 , PgBouncer n'attendra pas et tuera la connexion IMMÉDIATEMENT après que la transaction entre Odoo et PostgreSQL soit terminée. C'est le paramètre le plus agressif.

Avantages et inconvénients d'une valeur élevée (30 secondes dans le timing SQL est considéré comme élevé):

• AVANTAGE ⇒ Aucune ressource n'est conservée inutilement. PgBouncer récupère toute la mémoire et les connexions utilisées par Odoo. Cela signifie que l'optimisation mémoire la plus efficace est possible car il y aura plus de RAM disponible en permanence.

Cela signifie également que les connexions seront immédiatement disponibles. Ainsi, vous pouvez minimiser le problème de «connexion épuisée» d'Odoo car vous récupérez toutes les connexions possibles en temps réel.

• INCONVENIENT ⇒ Si vous avez de nombreuses connexions et demandes similaires provenant d'Odoo, tuer les connexions trop rapidement peut diminuer les performances car les connexions doivent être réouvertes:

Par exemple, avec des mécanismes récurrents comme la navigation sur le site Web, les travailleurs Odoo utiliseront principalement les mêmes connexions car les types d'accès pour la lecture des pages sont les mêmes pour les visiteurs anonymes.

b. Paramètre de taille de pool par défaut avec les systèmes Odoo

default_pool_size ⇒ Ce paramètre définit combien de connexions serveur vous souhaitez autoriser par paire utilisateur/base de données à l'intérieur du pooler PgBouncer. La valeur par défaut est 20.

Attention: si le nombre que vous définissez est trop bas, cela peut être trop agressif et avoir un impact négatif sur les performances. Si le nombre que vous définissez est trop élevé, cela peut permettre trop de connexions ouvertes; et votre PgBouncer deviendra inefficace et inutile.

Quel est le calcul correct avec Odoo, alors? Faisons une estimation approximative:

Disons que chaque utilisateur Odoo a besoin d'au moins une connexion ouverte (bien que nous sachions qu'Odoo a tendance à en ouvrir beaucoup plus en fonction des besoins de l'ORM)

Supposons également que seuls 30% des utilisateurs intensifs sont parfaitement concomitants (effectuant des actions précisément au même moment).

Nous pouvons alors supposer que l'activité des demandes nécessite que les connexions soient ouvertes pendant une période plus ou moins longue, et faisons de cela une variable ayant un impact sur les 30% supposés ci-dessus:

• Les demandes plus complexes des utilisateurs de haut niveau (approbation/déplacements en masse/tableaux de bord) donneront un indice de 2
• Les demandes d'utilisateurs standard des utilisateurs moyens (saisie des ventes / saisie des commandes d'achat / génération des mouvements d'entrepôt et suivi des entrées / sorties) donneront un indice de 1
• Les demandes d'utilisateurs simples du personnel peu impliqué (consultation uniquement / petites opérations / accès limité et autres utilisateurs légers) donneront un indice de 0,5

Le calcul arrondi serait le suivant:

• Avec 100 utilisateurs lourds (100 * (30% x 2) = 60
• Avec 300 utilisateurs moyens (300 * (30% x 1) = 100
• Avec 1000 utilisateurs faibles (1000 * (30% x 0.5) = 150

Par conséquent, avec un total de 50 utilisateurs humains simultanés du système Odoo, nous pourrions faire les hypothèses suivantes:

• 40 lourd utilisateurs intensifs ⇒ (40 * (30% x 2) = 24
• 10 faible utilisateurs intensifs ⇒ (10 * (30% x 0.5) = 2

Dans ce cas, la valeur recommandée default_pool_size serait de 24 + 2 = 26.

c. Taille minimale du pool

min_pool_size ⇒ Cela ajoutera plus de connexions serveur au pool si le pool tombe en dessous de cette valeur. La valeur est limitée à la taille du pool, ce qui signifie que la quantité minimale de connexions ne peut pas être supérieure à la quantité maximale. La valeur par défaut est 0.

L'utilisation de ce paramètre améliore les performances et le temps d'accès lorsque la charge habituelle revient soudainement après une période d'inactivité totale.

En pratique, cela peut se produire avec Odoo car nous constatons généralement deux temps d'arrêt spécifiques pendant la pause déjeuner et la pause du soir, tandis qu'ils sont repris en même temps par la plupart des utilisateurs aux mêmes heures de travail.

Par conséquent, cela a du sens pour certains types de déploiement Odoo avec des périodes d'utilisation faibles et élevées et une déviation de la concurrence des utilisateurs de haute qualité.

Comment le calculer avec Odoo, alors? Dans le cas mentionné ci-dessus, nous recommandons de prendre le paramètre default_pool_size et de le restreindre de 40%. Par conséquent, pour suivre notre exemple précédent de 50 utilisateurs, le calcul serait le suivant: 26 - 40% = 18 (arrondi à l'inférieur)

d. Max client conn

max_client_conn est le nombre maximum de connexions client autorisées. Lorsqu'il est augmenté, les limites des descripteurs de fichiers doivent également être augmentées.

Notez que le nombre réel de descripteurs de fichiers utilisés est supérieur à max_client_conn . Le maximum théorique utilisé est:

max_client_conn + (max pool_size * total databases * total users)

Mais dans le cas d'Odoo, un utilisateur de base de données est spécifié dans la chaîne de connexion (tous les utilisateurs se connectent sous le même nom d'utilisateur "odoo" tel que spécifié dans le fichier odoo.conf).

Par conséquent, le maximum théorique est:

max_client_conn + (max pool_size * total databases)

Pour effectuer ce calcul, vous devez d'abord utiliser les valeurs calculées dans les sections précédentes.

Cohérence entre les systèmes

Cette section vise à attirer votre attention sur la nécessité d'appliquer une logique stricte lors de la configuration du paramètre de connexions maximales dans les trois systèmes suivants:

1. Odoo moteur (à l'intérieur de odoo.conf avec le paramètre db_maxconn )
2. PgBouncer (à l'intérieur de pgbouncer.ini avec le paramètre max_client_conn )
3. PostgreSQL (à l'intérieur postgresql.conf avec le paramètre max_connections )

Conseil en 2 phrases:

Le paramètre max_connections d'Odoo ne doit PAS être inférieur à celui de PgBouncer. Les connexions PostgreSQL ne doivent JAMAIS être inférieures à celles de

PgBouncer. Les connexions PostgreSQL ne doivent JAMAIS être inférieures à celles de PgBouncer. sinon, cela pourrait générer une pénurie de connexions et une défaillance de PostgreSQL.

Utilisez avec prudence

Les messages et les préoccupations que j'ai reçus dans ma boîte de réception semblent indiquer que les expéditeurs étaient convaincus qu'il y avait ici des recettes magiques qui résoudraient miraculeusement tous leurs problèmes de performance Odoo.

Dans le cas d'Odoo, il existe de nombreuses autres approches à envisager, qui n'ont rien à voir avec PgBouncer, telles que:

• Mauvaise configuration, spécifications ou paramètres d'infrastructure
• Conception de module/flux de traitement faible
• Mauvaise gestion de la concurrence des tables
• Mauvaise gestion de la planification des requêtes
• Mauvaise gestion de l'approvisionnement des tuples
• Stratégies d'indexation faibles, manquantes, non adaptées ou redondantes
• Absence de gestion des requêtes lourdes
• Codage ORM Odoo faible et/ou modules complémentaires personnalisés.
• Dommages aux performances ETL et à la base de données induits par Odoo Studio
• Et la liste continue...

Pour résumer, rappelez-vous que PgBouncer est un middleware bénéfique qui gère très bien les sessions pour Odoo avec PostgreSQL.

Cependant, cela s'applique uniquement aux cas décrits précédemment et rien de plus. Sinon, cela entraînera une complexité accrue, des surcharges supplémentaires et une perte de performance.

Si vous avez des questions sur l'optimisation des performances d'Odoo, n'hésitez pas à contacter notre équipe d'experts .