Ich bin der Autor von pg-promise .
Es gibt mehrere Optimierungsstufen für die Datenbankkommunikation. Die wichtigste davon ist, die Anzahl der Abfragen pro HTTP-Anforderung zu minimieren, da IO teuer ist, ebenso wie der Verbindungspool.
- Wenn Sie mehr als eine Abfrage pro HTTP-Anfrage ausführen müssen, verwenden Sie immer Aufgaben über die Methode Aufgabe .
- Wenn Ihre Aufgabe eine Transaktion erfordert, führen Sie sie als Transaktion aus, über die Methode tx .
- Wenn Sie mehrere Einfügungen oder Aktualisierungen durchführen müssen, verwenden Sie immer Mehrzeilenoperationen. Siehe Mehrzeilige Einfügung mit pg-promise und mehrzeilige PostgreSQL-Updates in Node.js .
node-postgres begann mit der Verwendung von pg-pool ab Version 6.x, während pg-promise auf Version 5.x verbleibt, die die Implementierung des internen Verbindungspools verwendet. Hier ist der Grund dafür .
Meine langjährige Erfahrung in diesem Bereich legt nahe:Wenn Sie Ihren Dienst nicht in einen Pool von 20 Verbindungen einfügen können, werden Sie nicht gerettet, indem Sie sich für mehr Verbindungen entscheiden, Sie müssen stattdessen Ihre Implementierung korrigieren. Wenn Sie über 20 gehen, belasten Sie die CPU zusätzlich, und das führt zu einer weiteren Verlangsamung.
Die Größe der Daten hat nichts mit der Größe des Pools zu tun. Normalerweise verwenden Sie nur eine Verbindung für einen einzelnen Download oder Upload, egal wie groß. Sofern Ihre Implementierung nicht falsch ist und Sie am Ende mehr als eine Verbindung verwenden, müssen Sie das Problem beheben, wenn Sie möchten, dass Ihre App skalierbar ist.
Es wird auf die nächste verfügbare Verbindung gewartet.
Siehe auch:
