PostgreSQL Connection Pooling:Teil 4 – PgBouncer vs. Pgpool-II

In unseren vorherigen Beiträgen in dieser Serie haben wir ausführlich über die Verwendung von PgBouncer und Pgpool-II, die Architektur des Verbindungspools und die Vor- und Nachteile der Nutzung eines solchen gesprochen für Ihre PostgreSQL-Bereitstellung. In unserem letzten Beitrag werden wir sie in einem detaillierten Feature-Vergleich gegenüberstellen und die Ergebnisse der Leistung von PgBouncer vs. Pgpool-II für Ihr PostgreSQL-Hosting vergleichen!

Wie stapeln sich die Features?

Beginnen wir mit dem Vergleich der Funktionen von PgBouncer und Pgpool-II:

Unterm Strich – Pgpool-II ist ein großartiges Tool, wenn Sie Lastenausgleich und Hochverfügbarkeit benötigen. Das Verbindungspooling ist fast ein Bonus, den Sie nebenbei erhalten. PgBouncer macht nur eine Sache, aber macht es wirklich gut. Wenn das Ziel darin besteht, die Anzahl der Verbindungen zu begrenzen und den Ressourcenverbrauch zu reduzieren, gewinnt PgBouncer zweifellos.

Es ist auch völlig in Ordnung, sowohl PgBouncer als auch Pgpool-II in einer Kette zu verwenden – Sie können einen PgBouncer haben, um ein Verbindungspooling bereitzustellen, das mit a kommuniziert Pgpool-II-Instanz, die Hochverfügbarkeit und Lastenausgleich bietet. So erhalten Sie das Beste aus beiden Welten!

Leistungstest

Während PgBouncer theoretisch die bessere Option zu sein scheint, kann die Theorie oft irreführend sein. Also haben wir die beiden Verbindungspooler mit dem Standard-pgbench-Tool gegeneinander antreten lassen, um in einem Benchmark-Test zu sehen, welcher einen besseren Transaktionsdurchsatz pro Sekunde bietet. Zur Sicherheit haben wir die gleichen Tests auch ohne Connection Pooler durchgeführt.

Testbedingungen

Alle PostgreSQL-Benchmarktests wurden unter den folgenden Bedingungen durchgeführt:

1. Initialisierte pgbench mit einem Skalierungsfaktor von 100.
2. Auto-Vacuuming auf der PostgreSQL-Instanz deaktiviert, um Interferenzen zu vermeiden.
3. Kein anderer Workload funktionierte zu diesem Zeitpunkt.
4. Verwendet das standardmäßige pgbench-Skript, um die Tests auszuführen.
5. Verwendete Standardeinstellungen für PgBouncer und Pgpool-II, außer max_children *. Alle PostgreSQL-Limits wurden ebenfalls auf ihre Standardwerte gesetzt.
6. Alle Tests wurden als einzelner Thread auf einem Computer mit einer CPU und zwei Kernen für eine Dauer von 5 Minuten ausgeführt.
7. Zwingt pgbench, eine neue Verbindung für jede Transaktion mit der Option -C zu erstellen. Dies emuliert moderne Webanwendungs-Workloads und ist der einzige Grund, einen Pooler zu verwenden!

Wir haben jede Iteration 5 Minuten lang ausgeführt, um sicherzustellen, dass jegliches Rauschen gemittelt wird. So wurde die Middleware installiert:

• Für PgBouncer haben wir es auf demselben Rechner installiert wie die PostgreSQL-Server. Dies ist die Konfiguration, die wir in unseren verwalteten PostgreSQL-Clustern verwenden. Da PgBouncer ein sehr leichtgewichtiger Prozess ist, hat die Installation auf der Box keinen Einfluss auf die Gesamtleistung.
• Für Pgpool-II haben wir sowohl getestet, als die Pgpool-II-Instanz auf demselben Computer wie PostgreSQL (in der Box-Spalte) installiert war, und wenn sie auf einem anderen Computer installiert war (Off-Box-Spalte). Wie erwartet ist die Leistung viel besser, wenn Pgpool-II nicht einsatzbereit ist, da es nicht mit dem PostgreSQL-Server um Ressourcen konkurrieren muss.

Durchsatz-Benchmark

Hier sind die Ergebnisse der Transaktionen pro Sekunde (TPS) für jedes Szenario für eine Reihe von Clients:

Pgpool-II hängt, wenn pg_bench mit mehr Clients als max_children ausgeführt wird. Daher haben wir die max_children erhöht, um sie der Anzahl der Clients für jeden Testlauf anzupassen.

Wenn wir die prozentuale Erhöhung der TPS bei Verwendung eines Verbindungspoolers berechnen, erhalten wir Folgendes:

* Verbesserungsalgorithmus =(mit Pooler – ohne)/ohne

Schlussworte

Wie Sie den Leistungstestergebnissen entnehmen können, können eine gut konfigurierte Verbindung und ein gut geeigneter Verbindungspooler den Transaktionsdurchsatz drastisch erhöhen, selbst bei einer relativ kleinen Anzahl von Clients. Verbindungspooler sind besonders nützlich für ihre Warteschlangenunterstützung – wenn die Anzahl der Clients die vom PostgreSQL-Server unterstützte maximale Anzahl von Clients überschreitet, ist PgBouncer immer noch in der Lage, die Transaktionsrate aufrechtzuerhalten, während direkte Verbindungen zu PostgreSQL abgebrochen werden.

Ein schlecht konfigurierter Verbindungspooler kann jedoch tatsächlich reduzieren die Leistung, wie wir sie hier mit dem Pgpool-II-Setup gesehen haben. Ein Teil des Problems besteht darin, Pgpool-II doppelt zu verwenden die Anzahl der Prozesse, die auf demselben Server ausgeführt werden – wir müssen Führen Sie Pgpool-II auf einem separaten Server aus, um eine gute Leistung zu erzielen. Aber selbst dann schafft PgBouncer eine bessere Leistung für diese relativ kleine Anzahl von Clients.

Beachten Sie auch, dass der Test hier eigentlich perfekt für Pgpool-II erstellt wurde – da bei N> 32 die Anzahl der Clients und die Anzahl der untergeordneten Prozesse gleich waren, und daher, bei jeder erneuten Verbindung wurde garantiert, dass ein zwischengespeicherter Prozess gefunden wurde. Schon damals war PgBouncer die schnellere Alternative.

Unsere Tests zeigen also, dass PgBouncer die weitaus bessere Wahl für das Verbindungspooling ist. Es ist jedoch wichtig, sich daran zu erinnern, dass ein Verbindungspooler zwar für die meisten realistischen Workloads absolut obligatorisch ist, es jedoch von Ihrer Anwendung abhängt, ob Sie durch die Verwendung eines clientseitigen Pools oder von Middleware wie PgBouncer mehr gewinnen. Muster des Datenzugriffs würden eine Rolle spielen, ebenso wie die Latenzen, die aufgrund Ihrer Architektur auftreten. Wir empfehlen, Ihre Arbeitsbelastung mit beiden zu testen und dann die beste Vorgehensweise zu wählen – es gibt keine bessere Alternative zum Experimentieren!