nodejs + mysql: wann gepoolte Verbindungen zu verwenden?

Question

Zunächst weiß ich, dass es mehrere ähnliche Fragen gibt, aber sie beantworten nicht, was ich brauche, also lass mich diese neue öffnen :)

Zweitens ist diese Frage auf mysql konzentriert, aber nicht beschränkt auf es gilt auch für andere poolfähige Dienste wie memcached.

Soweit ich weiß, führt nodejs die Scripts single-threaded aus, aber es kann Threads erstellen, so dass es gleichzeitige Benutzer in einem Server verwalten kann. Aus diesem Grund ist es sinnvoll, einen Pool von Verbindungen zu erstellen.

Das Problem kommt, wenn ich diesen Test api per Express gedient haben, und ich führen Sie den folgenden Benchmark-Code:

ab -t 30 -c 1000 localhost/test 

mir die folgende Ausgabe für Single-Direkt Verbindung zur Datenbank zu geben:

Requests per second: 1732.07 [#/sec] (mean) 
Time per request: 577.344 [ms] (mean) 

in einem mySQL-Pool mit nur 1 Verbindung:

Requests per second: 1346.24 [#/sec] (mean) 
Time per request: 742.811 [ms] (mean) 

Und mit einem Pool mit 100 Verbindungen:

Requests per second: 662.82 [#/sec] (mean) 
Time per request: 1508.716 [ms] (mean) 

Welche sollte das Gegenteil sein, oder? Poolverbindung mit besserer Leistung.

Ich weiß, dass das Pooling-Management seine Zeit erfordert (soll aber nicht signifikant) und die SQL-Abfrage ist sehr einfach, aber ... IDK ...

Die API so etwas wie diese:

function test(response, request, dbc) { 
    dbc.query(SQL, PARAMS, (err, rows) => { 
    dbc.release(); 
    if(err) { 
     log.error('Error while performing the query', err.code); 
     return; 
    } 

    response.send(response, rows); 
    }); 
} 

wo dbc die Datenbankverbindung für einzelne/gepoolten Verbindungen abstrahiert ist, und dbc.release() tun nichts, wenn die Verbindung nicht aus einem Pool ist (der gleiche api Arbeit auf direkte/Pool-Verbindungen mit dem gleichen Code zu ermöglichen, nur eine Option zu ändern).

Fehle ich hier etwas?

Answer 1

Nur um ein kleines bisschen zu korrigieren: Node.js führt blockierungsfreie E/A-Operationen in einem einzigen Thread aus, so dass es mehrere Anfragen gleichzeitig bedienen kann (Interleaving) - so dass keine Threads für mehrere Benutzer benötigt werden .

Die lange Reaktionszeit mit Pooling scheint seltsam, das muss ich zugeben. Aber auch der Test ist recht einfach - fire eine Abfrage und schließe die Verbindung. Ich nehme an, es würde anfangen, besser zum Pooling zu schauen, wenn der Test etwas "funktioniert" hat, bevor die Verbindung gelöst wurde. Normalerweise sind Transaktionen geöffnet, mehrere Anweisungen ausgeführt und so weiter. Sie können dies mit einer einfachen Verzögerung vor dem Loslassen der Verbindung nachahmen - zum Beispiel 2 Sekunden.

Sie können mehr darüber lesen, wie Node-Server zum Beispiel Anfragen von einem einzigen Thread läuft in "Node.js: 100 new requests while still serving the first one!"

Answer 2

hier Ok ist, wo ich denke, dass man nichts falsch machen, wenn Sie eine einzelne Verbindung zu erstellen jedes Mal, wenn Sie auffordern, seine schneller, da es nur eine Verbindung über das Netzwerk geöffnet werden, bevor Sie eine Abfrage ausführen, wenn Sie das gleiche mit gepoolten Verbindung tun, die es geöffnet werden muss, sagen Sie 100 Verbindungen, bevor es beginnt, eine Abfrage auszuführen. im Grunde, um 100 Verbindungen zu erwerben, bevor es irgendetwas tun kann, wo es in einer einzelnen Verbindung nur eine Verbindung erhalten muss.Jetzt ist es nicht sinnvoll, eine Verbindung jedes Mal zu schließen, wenn eine Anforderung bei Verwendung von pool endet. Der ganze Sinn der Pooling-Verbindungen ist Verbindungen wieder zu verwenden, so dass Sie eine neue Verbindung nicht jedes Mal einen Netzwerk-Hop zu tun haben, zu öffnen, reduziert Latenzzeiten und vermeidet Netzwerk-Handshake auf jeder Anfrage. Ja