MySQL - Permanente Verbindung vs Verbindungspooling
Um zu vermeiden, dass der overhead für das aufbauen einer neuen Verbindung jedes mal eine Abfrage braucht, abgefeuert gegen MySQL gibt es zwei Optionen zur Verfügung:
- Persistente verbindungen, wodurch eine neue Verbindung angefordert wird, wird eine Prüfung durchgeführt, um zu sehen, ob eine 'identische' Verbindung bereits geöffnet ist und wenn ja, verwenden Sie es.
- Verbindungs-pooling, wobei der client verwaltet einen pool von verbindungen, so dass jeder thread, muss eine Verbindung verwendet wird, Lesen Sie in einem aus dem pool aus und senden es zurück an den pool, wenn Sie fertig.
So, wenn ich eine multi-threaded-server-Anwendung erwartet von tausenden von Anfragen pro Sekunde, und jeder thread muss das Feuer eine Abfrage gegen die Datenbank, was ist dann die bessere Wahl?
Aus meinem Verständnis, Mit persistenten verbindungen, alle threads in meiner Anwendung wird versuchen und verwenden Sie die gleiche dauerhafte Verbindung mit der Datenbank, da Sie alle identische verbindungen. So ist es eine Verbindung gemeinsam von mehreren Anwendungs-threads - als Ergebnis der Anfragen wird der block auf der Datenbank-Seite bald.
Wenn ich ein connection-pooling-Mechanismus, ich werde alle Anwendungs-threads teilen sich einen pool von verbindungen. So gibt es weniger Möglichkeit, eine Sperrung verlangen. Allerdings mit Verbindungs-pooling, sollte eine Anwendung thread warten, um zu erwerben, eine Verbindung aus dem pool, oder sollten Sie eine Anfrage zu senden auf die verbindungen im pool sowieso in einer round-robin-Weise, und lassen Sie die Warteschlangen, wenn überhaupt, zufällig auf der Datenbank?
InformationsquelleAutor der Frage user1259642 | 2012-03-16
Du musst angemeldet sein, um einen Kommentar abzugeben.
Mit persistenten verbindungen bedeutet nicht, dass alle threads dieselbe Verbindung verwenden. Ist es einfach "sagt", dass Sie, um die Verbindung zu öffnen (im Widerspruch zum öffnen einer Verbindung jedes mal, wenn Sie eine brauchen). Das öffnen einer Verbindung ist eine teure operation, so dass - im Allgemeinen - Sie versuchen zu vermeiden, öffnen von verbindungen oft mehr als nötig.
Dies ist der Grund, warum Multithread-Anwendungen nutzen den connection-pools. Der pool kümmert sich um das öffnen und schließen von verbindungen und jeder thread, der eine Verbindung anfordert, die aus dem pool. Es ist wichtig, darauf zu achten, dass der thread gibt die Verbindung so bald wie möglich, um den pool, so dass ein anderer thread die es nutzen können.
Wenn Ihre Anwendung nur ein paar lange Laufenden threads, verbindungen benötigen, können Sie auch öffnen, eine Verbindung für jeden thread durch und bewahren Sie diese öffnen.
Verwendung nur einer Verbindung (wie du es beschrieben hast) gleich einen connection pool mit der maximalen Größe. Dies wird früher oder später dein Flaschenhals, da alle threads müssen warten, für die Verbindung. Dies könnte eine option sein, die zum serialisieren des Datenbank-Operationen (führen Sie in einer bestimmten Reihenfolge), allerdings gibt es bessere Optionen, um sicherzustellen, serialisieren.
InformationsquelleAutor der Antwort mrab
Bezüglich Ihrer Frage über die sollte der application-server auf eine Verbindung gewartet, die Antwort ist ja.
MySQL-verbindungen werden blockiert. Wenn Sie eine Anfrage von MySQL-server über eine Verbindung, die Verbindung wird warten, im Leerlauf, bis eine Antwort vom server empfangen wird.
Gibt es keine Möglichkeit zum senden von zwei Anfragen auf die gleiche Verbindung und sehen, welche Renditen erste. Sie können nur senden Sie eine Anfrage an ein Zeit.
So, in der Regel, einen einzigen thread in einem connection-pool besteht aus einer client-Seite Verbindung (in deinem Fall die Anwendungs-server ist der client) und einem server-side-Anschluss (Datenbank).
Sollte Ihre Anwendung eine verfügbare Verbindung warten, den thread aus dem pool, so dass der pool zu wachsen, wenn Sie gebraucht wird, und zu schrumpfen, zurück zu Ihrem Standard Anzahl von threads, wenn es weniger beschäftigt.
InformationsquelleAutor der Antwort Marcus Adams