Table of Contents
Regroupement de connexions Signification
Un pool de connexions est un cache de connexions à la base de données maintenu afin que les connexions puissent être réutilisées lorsque de futures demandes à la base de données sont requises. Les pools de connexion sont utilisés pour améliorer les performances d’exécution des commandes sur une base de données. L’ouverture et la maintenance d’une connexion à la base de données pour chaque utilisateur, en particulier les requêtes adressées à une application dynamique pilotée par une base de données, sont coûteuses et gaspillent des ressources. Dans le regroupement de connexions, une fois qu’une connexion est créée, elle est placée dans le pool et elle est réutilisée afin qu’une nouvelle connexion n’ait pas à être établie.
Vous pouvez également définir un nombre maximum de connexions qu’un pool va créer, et cela peut être très intéressant pour réduire le nombre de licences de bases de données nécessaires. Dans un tel cas, lorsque le pool atteint la limite et qu’une nouvelle requête arrive, cette requête ne sera pas traitée si une connexion vacante n’est pas rendue disponible avant un certain délai préalablement défini.
La clé d’un pooling de connexions avec des connexions à la base de données limitées est de définir le nombre idéal pour ce pool en fonction du nombre final d’utilisateurs et de l’architecture de l’application. Plus d’informations à ce sujet dans l’exemple ci-dessous.
Le mécanisme de regroupement de connexions FireDAC
Le mécanisme de regroupement de connexions de FireDAC est assez facile à utiliser et peut être activé en définissant une seule propriété de connexion supplémentaire à partir de votre connexion (Pooled=True).
Bien sûr, la fonctionnalité de pooling brille dans les applications multi-threads, où plusieurs tâches courtes sont exécutées simultanément (ou presque), et chacune de ces tâches nécessite l’établissement d’une connexion. Lors de l’utilisation de la fonction d’interrogation, la connexion sera déjà établie et en attente de la tâche, ce qui se traduira par un temps de traitement beaucoup plus rapide et moins de consommation de ressources.
Pour les scénarios avancés, outre le paramètre « Pooled », trois autres paramètres peuvent être pris en compte :
| Paramètre | Paramètre | Exemple |
|---|---|---|
| POOL_CleanupTimeout | Le temps (msecs) jusqu’à ce que FireDAC supprime les connexions qui n’ont pas été utilisées depuis plus longtemps que le temps POOL_ExpireTimeout. La valeur par défaut est 30 000 ms (30 s). | 3600000 |
| POOL_ExpireTimeout | Le temps (msecs) après lequel la connexion inactive peut être supprimée du pool et détruite. La valeur par défaut est 90 000 ms (90 s). | 600000 |
| POOL_MaximumItems | Le nombre maximum de connexions dans le pool. Lorsque l’application nécessite plus de connexions, une exception est déclenchée. La valeur par défaut est 50. | 100 |
FireDAC vous permet d’utiliser des connexions « persistantes » (stockées dans le fichier .ini de FireDAC), des connexions « privées » (disponibles en mémoire pour une application) et « temporaires » (non stockées et non nommées ni gérées par le FDManager). Vous pouvez en savoir plus sur la définition et l’établissement d’une connexion (avec ou sans pool) en suivant la documentation ci-dessous :
- https://docwiki.embarcadero.com/RADStudio/en/Multithreading_(FireDAC)
- https://docwiki.embarcadero.com/RADStudio/en/Defining_Connection_(FireDAC)
Regroupement de connexions avec RAD Server (EMS)
Pour toute application backend sérieuse, y compris RAD Server, il est presque obligatoire de disposer d’un mécanisme de pooling à mesure que le nombre d’appels vers votre application augmente. Notre exemple démontrera que l’utilisation d’une connexion « Privée » définie via le FDManager. Bien sûr, vous pouvez également réutiliser les connexions déjà définies dans le fichier .ini du FireDAC, ou même charger le fichier .ini via le FDManager et le modifier en ajoutant les paramètres de regroupement de connexions spécifiques à votre application serveur, mais pas très utiles dans une application de bureau.
Notre application de démonstration a été créée à l’aide de l’ assistant RAD Server ( https://docwiki.embarcadero.com/RADStudio/en/Creating_a_RAD_Server_Package ) et en utilisant la ressource EMSDataSetResource récemment ajoutée ( https://docwiki.embarcadero.com/RADStudio/en/ Using_RAD_Server_Components et https://blogs.embarcadero.com/using-emsdatasetresource-component-with-rad-server/ ), mais il en va de même pour les points de terminaison RAD Server définis explicitement.
Il est important de noter qu’une seule instance de FDManager peut exister par instance d’application. Vous remarquerez donc que le FDManager est créé dans la section d’ initialisation de notre ressource EMS, comme ceci :
Exécution d’un test de résistance avec notre projet de démonstration
La vidéo ci-dessous montre le mécanisme de regroupement testé à l’aide de JMeter avec une charge totale de 100 utilisateurs :
En guise de conseil supplémentaire, si votre application RAD Server est composée de plusieurs packages, vous pouvez toujours utiliser le mécanisme de mise en pool. Tout ce que vous avez à faire est de créer une ressource RAD Server qui vise uniquement à définir la configuration du regroupement de connexions par le FDManager, et assurez-vous de charger cette ressource en premier dans votre environnement de déploiement.