L’importance de bien régler ses Datasources

Je ne sais pas pour vous, mais le projet sur lequel je me trouve en ce moment (et ce n'est pas le seul) n'a pas prêté grande attention au paramétrage de ces datasources. Le projet  a pris la fâcheuse manie de positionner la capacité initiale d'un pool de connexion directement à sa valeur maximale. L'idée étant d'épargner la gestion dynamique du pool au serveur d'application (et puis surtout, il fallait positionner une valeur alors pourquoi pas celle là).

Dans cette situation, lorsqu'on regarde le comportement du pool pendant un test de charge, voici ce qui se passe :

Comportement du pool sans gestion dynamique

Comportement du pool sans gestion dynamique

Conformément à ce qu'on lui a indiqué, la capacité du pool est continuellement à 30 et le nombre de connexions actives oscille en fonction des besoins de l'application. L'application a longtemps vécu ainsi, cette configuration a gentillement été ignorée, le monde était heureux et en paix.

Mais (parce qu'à ce moment du récit, il faut un "mais"), soudain, les problèmes survinrent en production. Et ces problèmes se manifestèrent sous forme d'alertes sur la consommation mémoire au niveau de la base de données sous jacente. La solution fut rapide à trouver, elle a simplement consisté à laisser la gestion de la taille du pool directement au serveur d'application (une taille initiale à 0 et positionnement d'une fréquence de shrink) :

Comportement du pool avec gestion dynamique

Comportement du pool avec gestion dynamique

On voit bien que la capacité du pool s'adapte au besoin. Mais ce qui est étonnant, ce sont les gains obtenus. Le graphique ci-dessous montre la consommation de la PGA (une zone mémoire bien particulière) sur la base de données. Entre le 25/06 et le 28/06, nous avons effectué des tests sans gestion dynamique du pool. Du 28/06 au 30/06, nous avons effectué des tests avec la gestion dynamique du pool de connexion.

Consommation mémoire PGA

Consommation mémoire PGA

C'est donc environ 6 Go de mémoire brute que nous avons économisé et c'était bien au delà de ce nous envisagions. Ces chiffres sont à relativiser car dans notre cas de figure, nous avions 6 instances Weblogic qui utilisent chacune un pool sur cette base. Mais cela représente tout de même 1 Go par instance.

Et la surprise est venu aussi des temps de réponses utilisateurs mesurés pendant nos tests, nous avons observé des gains d'environ 10%. Ce point reste à confirmer car, d'une part,  je ne l'explique pas vraiment (peut être le temps d'attente d'une connexion est-il moindre grâce à un pool à parcourir plus petit) et, d'autre part, je ne dispose de pas beaucoup de mesures.

La morale de cette histoire est donc de ne pas négliger la configuration de vos datasources et de les dimensionner au plus juste. Cette expérience a été menée avec des serveurs Weblogic et une base de données Oracle mais je suis sûr qu'elle pourrait être réitérée avec n'importe quelle produit.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Captcha *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.