Je suis l'auteur de pg-promise .
Il existe plusieurs niveaux d'optimisation pour les communications de base de données. Le plus important d'entre eux est de minimiser le nombre de requêtes par requête HTTP, car les E/S coûtent cher, tout comme le pool de connexions.
- Si vous devez exécuter plus d'une requête par requête HTTP, utilisez toujours des tâches, via la méthode tâche .
- Si votre tâche nécessite une transaction, exécutez-la en tant que transaction, via la méthode tx .
- Si vous devez effectuer plusieurs insertions ou mises à jour, utilisez toujours des opérations sur plusieurs lignes. Voir Insert multi-lignes avec pg-promise et Mises à jour multi-lignes PostgreSQL dans Node.js .
node-postgres a commencé à utiliser pg-pool à partir de la version 6.x, tandis que pg-promise reste sur la version 5.x qui utilise l'implémentation du pool de connexions interne. Voici la raison pour laquelle .
Ma longue pratique dans ce domaine suggère :si vous ne pouvez pas intégrer votre service dans un pool de 20 connexions, vous ne serez pas sauvé en optant pour plus de connexions, vous devrez plutôt corriger votre implémentation. De plus, en dépassant 20, vous commencez à solliciter davantage le processeur, ce qui se traduit par un ralentissement supplémentaire.
La taille des données n'a rien à voir avec la taille du pool. Vous n'utilisez généralement qu'une seule connexion pour un seul téléchargement ou téléchargement, quelle que soit sa taille. À moins que votre implémentation ne soit erronée et que vous finissiez par utiliser plusieurs connexions, vous devez la corriger si vous souhaitez que votre application soit évolutive.
Il attendra la prochaine connexion disponible.
Voir aussi :
