Option 1. Le partage d'une connexion de base de données unique entre tous les utilisateurs Web est voué à l'échec pour une raison ou une autre. Une requête longue durée et votre serveur entier s'arrêtera. C'est un "non" difficile et rapide pour 99,9% de toutes les applications modernes, même les applications non basées sur le Web.
Option 2. Regroupement de connexions. Probablement la deuxième technique la plus couramment utilisée pour une application web pour se connecter à une base de données. Tout d'abord, les avantages sont extrêmement limités si la base de données et l'application Pool/Web sont sur la même machine. Le pool et l'application web, cependant peuvent facilement exister sur le même matériel. L'avantage ici est que les connexions à une base de données sont coûteuses à ouvrir et, dans une moindre mesure, coûteuses à garder ouvertes. L'ouverture d'une connexion nécessite l'utilisation du processeur et l'allocation de mémoire. La mise en commun des connexions peut permettre à quelques douzaines de connexions d'être "attachées" presque instantanément. La mémoire sera déjà allouée et la plupart des travaux d'installation seront déjà effectués, donc la connexion et la déconnexion de la piscine est relativement rapide. Les pools maintiennent généralement un certain nombre de connexions ouvertes à tout moment et augmentent au fur et à mesure que le trafic augmente. En période de trafic excessif, les pools mettent généralement en file d'attente les demandes de connexion afin que la base de données ne soit pas surchargée. Les utilisateurs situés à la fin de la file d'attente rencontrent des retards, mais le système est généralement interrompu. et échange de disque.
Option 3. Nouvelle connexion à la base de données par requête. Sur un système léger à modérément utilisé, ce n'est pas une option terrible, et il est généralement facile de passer à un pooler à une date ultérieure. Gardez à l'esprit, toutefois, que chaque connexion à une base de données (chaque chargement de page) nécessitera l'ouverture et la fermeture d'une connexion DB, ce qui impliquait une allocation de CPU et de mémoire. En pratique, si vos pages se chargent rapidement, votre base d'utilisateurs est petite et cohérente, et votre trafic est assez constant, cela peut très bien fonctionner. De nombreux environnements DEV, CAT et QA sont directement connectés sans pooler. L'inconvénient est # 1, il n'y a absolument aucun moyen de contrôler les connexions à la base de données. Si les requêtes se bloquent, vous pouvez avoir des centaines de connexions qui détruisent soudainement votre base de données et parfois un redémarrage ou un redémarrage de la base de données est nécessaire pour rectifier la situation. Par exemple: Vous écrivez 1 mauvaise requête qui se trouve sur la page d'accueil de votre site, ce qui entraîne l'exécution de 3 secondes au lieu de 0,3 seconde. Finalement, votre site qui a eu 1-2 pages en cours d'exécution à un moment donné, peut maintenant augmenter jusqu'à 10-20. Maintenant, ces 10-20 pages = 10-20 connexions DB ouvrant et fermant constamment, avec 10-20 étant ouvert en moyenne. Ce problème surgira, en utilisant de plus en plus de mémoire jusqu'à ce que vous atteigniez la limite de connexion (ou pire, utilisez toute la mémoire et tout ce qui change maintenant). À ce stade, tout s'arrête. N'oubliez pas que les connexions occupent des ressources à la fois sur la base de données et sur le serveur/pool d'applications. Lorsque votre base de données effectue une pagination sur disque, la plupart du temps, tout espoir est perdu pour une récupération élégante sans réinitialiser quelque chose ... Évidemment, cela peut arriver, mais sans correction de code, vous redémarrez habituellement pour vous donner plus de temps avant le problème. arrive à nouveau, et j'espère que d'ici là, vous avez trouvé la mauvaise requête, ou mauvaise config et l'a réparée.
L'option 2 vous donne le plus d'options. Ce n'est généralement pas un casse-tête de gestion, mais si vous l'exécutez sur une seule machine, les avantages sont limités. Si vous disposez d'au moins deux machines (serveur d'applications et serveur de base de données), il s'agit d'une solution simple qui empêche généralement de nombreuses surcharges système.