TOC

Verbindungspools für verwaltete Datenbanken und PostgreSQL-Benchmarking mit pgbench

Einführung

Mit DigitalOcean Managed Databases können Sie Ihre PostgreSQL-Datenbank mit verschiedenen Methoden skalieren. Eine solche Methode ist ein integrierter Verbindungspooler, mit dem Sie eine große Anzahl von Clientverbindungen effizient verwalten und den CPU- und Speicherbedarf dieser offenen Verbindungen verringern können. Durch die Verwendung eines Verbindungspools und die gemeinsame Nutzung eines festen Satzes wiederverwendbarer Verbindungen können Sie erheblich mehr gleichzeitige Clientverbindungen verarbeiten und die Leistung Ihrer PostgreSQL-Datenbank optimieren.

In diesem Tutorial verwenden wir + pgbench +, das in PostgreSQL integrierte Benchmarking-Tool, um Auslastungstests für eine von DigitalOcean verwaltete PostgreSQL-Datenbank durchzuführen. Wir werden uns mit Verbindungspools befassen, deren Funktionsweise beschreiben und zeigen, wie Sie einen Pool mithilfe des Cloud-Steuerungsfelds erstellen. Schließlich zeigen wir anhand der Ergebnisse der "+ pgbench +" - Tests, wie die Verwendung eines Verbindungspools eine kostengünstige Methode zur Steigerung des Datenbankdurchsatzes sein kann.

Voraussetzungen

Um dieses Tutorial abzuschließen, benötigen Sie:

  • Ein von DigitalOcean verwaltetes PostgreSQL-Datenbank-Cluster. Informationen zum Bereitstellen und Konfigurieren eines DigitalOcean PostgreSQL-Clusters finden Sie in der Managed Database product documentation.

  • Ein Client-Computer, auf dem PostgreSQL installiert ist. Standardmäßig enthält Ihre PostgreSQL-Installation das Benchmarking-Dienstprogramm "+ pgbench " und den Client " psql +", die beide in diesem Handbuch verwendet werden. Informationen zur Installation und Verwendung von PostgreSQL unter Ubuntu 18.04 finden Sie unter https://www.digitalocean.com/community/tutorials/how-to-install-and-use-postgresql-on-ubuntu-18-04 PostgreSQL. Wenn Sie Ubuntu nicht auf Ihrem Client-Computer ausführen, können Sie den Versionsfinder verwenden, um das entsprechende Tutorial zu finden.

Sobald Sie einen DigitalOcean PostgreSQL-Cluster eingerichtet und einen Client-Computer mit "+ pgbench +" installiert haben, können Sie mit diesem Handbuch beginnen.

Schritt 1 - Erstellen und Initialisieren von + benchmark + Database

Bevor wir einen Verbindungspool für unsere Datenbank erstellen, erstellen wir zunächst die "+ Benchmark " - Datenbank in unserem PostgreSQL-Cluster und füllen sie mit einigen Dummy-Daten, auf denen " pgbench " seine Tests ausführen wird. Das Dienstprogramm " pgbench " führt wiederholt eine Reihe von fünf SQL-Befehlen (bestehend aus " SELECT ", " UPDATE " und " INSERT " - Abfragen) in einer Transaktion unter Verwendung mehrerer Threads und Clients aus und berechnet eine nützliche Leistungsmetrik genannt ** T ** Transaktionen ** p ** er ** S ** zweite (TPS). TPS ist ein Maß für den Datenbankdurchsatz und zählt die Anzahl der von der Datenbank verarbeiteten atomaren Transaktionen in einer Sekunde. Weitere Informationen zu den spezifischen Befehlen, die von " pgbench " ausgeführt werden, finden Sie unter https://www.postgresql.org/docs/10/pgbench.html#id-1.9.4.10.7.2[Was ist die "Transaktion", die tatsächlich ausgeführt wird? pgbench?] aus der offiziellen ` pgbench +` Dokumentation.

Stellen Sie zunächst eine Verbindung zu unserem PostgreSQL-Cluster her und erstellen Sie die Datenbank "+ benchmark +".

Rufen Sie zunächst die * Verbindungsdetails * Ihres Clusters ab, indem Sie zu * Databases * navigieren und Ihren PostgreSQL-Cluster suchen. Klicken Sie in Ihren Cluster. Sie sollten eine Cluster-Übersichtsseite sehen, die das folgende Feld * Verbindungsdetails * enthält:

image: https://assets.digitalocean.com/articles/managed_db_pools/conn_details.png [Details zur PostgreSQL-Clusterverbindung]

Daraus können wir die folgenden Konfigurationsvariablen analysieren:

  • Administrator: + doadmin +

  • Administrator-Passwort:

  • Cluster-Endpunkt: + dbaas-test-do-user-3587522-0.db.on digitalocean.com

  • Verbindungsport: + 25060 +

  • Zu verbindende Datenbank: + defaultdb +

  • SSL-Modus: + erfordern + (verwenden Sie eine SSL-verschlüsselte Verbindung für erhöhte Sicherheit)

Beachten Sie diese Parameter, da Sie sie benötigen, wenn Sie sowohl den + psql + Client als auch das + pgbench + Tool verwenden.

Klicken Sie auf das Dropdown-Menü über diesem Feld und wählen Sie * Verbindungszeichenfolge * aus. Wir kopieren diesen String und übergeben ihn an "+ psql +", um eine Verbindung zu diesem PostgreSQL-Knoten herzustellen.

Stellen Sie mit + psql + und der gerade kopierten Verbindungszeichenfolge eine Verbindung zu Ihrem Cluster her:

psql postgresql://doadmin:@:25060/defaultdb?sslmode=require

Sie sollten die folgende PostgreSQL-Client-Eingabeaufforderung sehen, die angibt, dass Sie erfolgreich eine Verbindung zu Ihrem PostgreSQL-Cluster hergestellt haben:

Outputpsql (10.6 (Ubuntu 10.6-0ubuntu0.18.04.1))
SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, compression: off)
Type "help" for help.

defaultdb=>

Erstellen Sie von hier aus die + benchmark + Datenbank:

CREATE DATABASE benchmark;

Sie sollten die folgende Ausgabe sehen:

OutputCREATE DATABASE

Trennen Sie nun die Verbindung zum Cluster:

\q

Bevor wir die "+ pgbench " - Tests ausführen, müssen wir diese " Benchmark +" - Datenbank mit einigen Tabellen und Dummy-Daten füllen, die zum Ausführen der Tests erforderlich sind.

Dazu führen wir "+ pgbench +" mit den folgenden Flags aus:

  • + -h +: Der PostgreSQL-Cluster-Endpunkt

  • + -p +: Der PostgreSQL-Cluster-Verbindungsport

  • + -U +: Der Datenbank-Benutzername

  • + -i +: Gibt an, dass wir die + Benchmark + - Datenbank mit Benchmarking-Tabellen und ihren Dummy-Daten initialisieren möchten.

  • + -s +: Stellen Sie einen Skalierungsfaktor von 150 ein, wodurch die Tabellengröße mit 150 multipliziert wird. Der Standard-Skalierungsfaktor von "+ 1 +" führt zu Tabellen der folgenden Größen:

    table                   # of rows
---------------------------------
pgbench_branches        1
pgbench_tellers         10
pgbench_accounts        100000
pgbench_history         0

    + Unter Verwendung eines Skalierungsfaktors von 150 enthält die Tabelle + pgbench_accounts + 15.000.000 Zeilen.

Führen Sie den vollständigen Befehl + pgbench + aus:

pgbench -h  -p 25060 -U doadmin -i -s 150 benchmark

Nachdem Sie diesen Befehl ausgeführt haben, werden Sie aufgefordert, das Kennwort für den von Ihnen angegebenen Datenbankbenutzer einzugeben. Geben Sie das Passwort ein und drücken Sie + ENTER.

Sie sollten die folgende Ausgabe sehen:

Outputdropping old tables...
NOTICE:  table "pgbench_accounts" does not exist, skipping
NOTICE:  table "pgbench_branches" does not exist, skipping
NOTICE:  table "pgbench_history" does not exist, skipping
NOTICE:  table "pgbench_tellers" does not exist, skipping
creating tables...
generating data...
100000 of 15000000 tuples (0%) done (elapsed 0.19 s, remaining 27.93 s)
200000 of 15000000 tuples (1%) done (elapsed 0.85 s, remaining 62.62 s)
300000 of 15000000 tuples (2%) done (elapsed 1.21 s, remaining 59.23 s)
400000 of 15000000 tuples (2%) done (elapsed 1.63 s, remaining 59.44 s)
500000 of 15000000 tuples (3%) done (elapsed 2.05 s, remaining 59.51 s)
. . .
14700000 of 15000000 tuples (98%) done (elapsed 70.87 s, remaining 1.45 s)
14800000 of 15000000 tuples (98%) done (elapsed 71.39 s, remaining 0.96 s)
14900000 of 15000000 tuples (99%) done (elapsed 71.91 s, remaining 0.48 s)
15000000 of 15000000 tuples (100%) done (elapsed 72.42 s, remaining 0.00 s)
vacuuming...
creating primary keys...
done.

Zu diesem Zeitpunkt haben wir eine Benchmarking-Datenbank erstellt, die mit den Tabellen und Daten gefüllt ist, die zum Ausführen der "+ pgbench +" - Tests erforderlich sind. Jetzt können wir einen Basistest ausführen, mit dem wir die Leistung vor und nach dem Aktivieren des Verbindungspools vergleichen.

Schritt 2 - Ausführen eines Baseline + pgbench + Tests

Bevor wir unseren ersten Benchmark durchführen, lohnt es sich, in das einzutauchen, was wir mit Verbindungspools optimieren möchten.

Wenn ein Client eine Verbindung zu einer PostgreSQL-Datenbank herstellt, teilt sich der Hauptprozess von PostgreSQL OS in der Regel in einen untergeordneten Prozess auf, der dieser neuen Verbindung entspricht. Wenn es nur wenige Verbindungen gibt, ist dies selten ein Problem. Mit zunehmender Skalierung von Clients und Verbindungen steigt jedoch der CPU- und Arbeitsspeicheraufwand für das Erstellen und Verwalten dieser Verbindungen, insbesondere wenn die betreffende Anwendung die Datenbankverbindungen nicht effizient nutzt. Darüber hinaus kann die Einstellung + max_connections + PostgreSQL die Anzahl der zulässigen Clientverbindungen begrenzen, was dazu führt, dass zusätzliche Verbindungen abgelehnt oder abgebrochen werden.

image: https://assets.digitalocean.com/articles/managed_db_pools/no_connection_pool.png [Datenbankverbindungen ohne Pooling]

Ein Verbindungspool hält eine feste Anzahl von Datenbankverbindungen offen, die * Poolgröße *, die dann zum Verteilen und Ausführen von Clientanforderungen verwendet wird. Dies bedeutet, dass Sie weitaus mehr gleichzeitige Verbindungen unterbringen, inaktive oder stagnierende Clients effizient bearbeiten sowie Clientanforderungen während Verkehrsspitzen in die Warteschlange stellen können, anstatt sie abzulehnen. Durch das Recycling von Verbindungen können Sie die Ressourcen Ihres Computers in einer Umgebung mit hohem Verbindungsvolumen effizienter nutzen und die zusätzliche Leistung Ihrer Datenbank optimieren.

image: https: //assets.digitalocean.com/articles/managed_db_pools/with_connection_pool.png [Datenbankverbindungen mit Pooling]

Ein Verbindungspool kann entweder auf der Anwendungsseite oder als Middleware zwischen der Datenbank und Ihrer Anwendung implementiert werden. Der Verbindungspooler für verwaltete Datenbanken basiert auf pgBouncer, einem kompakten Open-Source-Middleware-Verbindungspooler für PostgreSQL. Die Benutzeroberfläche ist über die Benutzeroberfläche des Cloud Control Panels verfügbar.

Navigieren Sie in der Systemsteuerung zu "Datenbanken" und klicken Sie auf Ihren PostgreSQL-Cluster. Klicken Sie von hier aus in "Verbindungspools". Klicken Sie anschließend auf * Verbindungspool erstellen *. Sie sollten das folgende Konfigurationsfenster sehen:

image: https://assets.digitalocean.com/articles/managed_db_pools/connection_pool_blank.png [Konfigurationsfenster für Verbindungspools]

Hier können Sie folgende Felder konfigurieren:

  • * Poolname *: Ein eindeutiger Name für Ihren Verbindungspool

  • * Datenbank *: Die Datenbank, für die Sie Verbindungen bündeln möchten

  • * Benutzer *: Der PostgreSQL-Benutzer, als den sich der Verbindungspool authentifiziert

  • * Modus *: Eine von * Sitzung *, * Transaktion * oder * Anweisung *. Diese Option steuert, wie lange der Pool einem Client eine Backend-Verbindung zuweist.

  • * Sitzung *: Der Client behält die Verbindung bei, bis die Verbindung explizit getrennt wird.

  • * Transaktion *: Der Client erhält die Verbindung, bis er eine Transaktion abgeschlossen hat. Anschließend wird die Verbindung an den Pool zurückgegeben.

  • * Anweisung *: Der Pool führt nach jeder Clientanweisung ein aggressives Recycling von Verbindungen durch. Im Anweisungsmodus sind Transaktionen mit mehreren Anweisungen nicht zulässig. Weitere Informationen finden Sie in der Produktdokumentation zu Connection Pools unter product documentation.

  • * Poolgröße *: Die Anzahl der Verbindungen, die der Verbindungspool zwischen sich und der Datenbank offen hält.

Bevor wir einen Verbindungspool erstellen, führen wir einen Basistest durch, mit dem wir die Datenbankleistung mit dem Verbindungspooling vergleichen können.

In diesem Lernprogramm wird ein Setup für eine verwaltete Datenbank mit 4 GB RAM, 2 vCPU und 80 GB Festplatte (nur Primärknoten) verwendet. Sie können die Benchmark-Testparameter in diesem Abschnitt gemäß Ihren PostgreSQL-Cluster-Spezifikationen skalieren.

In DigitalOcean Managed Database-Clustern ist der Parameter PostgreSQL + max_connections + auf 25 Verbindungen pro 1 GB RAM voreingestellt. Ein 4 GB RAM PostgreSQL-Knoten hat daher + max_connections + auf 100 gesetzt. Außerdem sind für alle Cluster 3 Verbindungen für die Wartung reserviert. Für diesen 4-GB-RAM-PostgreSQL-Cluster stehen 97 Verbindungen für das Verbindungspooling zur Verfügung.

Lassen Sie uns in diesem Sinne unseren ersten Basistest "+ pgbench +" durchführen.

Melden Sie sich bei Ihrem Client-Computer an. Wir führen "+ pgbench +" aus und geben wie gewohnt den Datenbankendpunkt, den Port und den Benutzer an. Darüber hinaus stellen wir die folgenden Flags zur Verfügung:

  • + -c +: Die Anzahl der gleichzeitig zu simulierenden Clients oder Datenbanksitzungen. Wir setzen dies auf 50, um eine Anzahl gleichzeitiger Verbindungen zu simulieren, die kleiner als der Parameter "+ max_connections +" für unseren PostgreSQL-Cluster sind.

  • + -j +: Die Anzahl der Worker-Threads + pgbench +, mit denen der Benchmark ausgeführt wird. Wenn Sie einen Computer mit mehreren CPUs verwenden, können Sie dies nach oben optimieren, um Clients auf mehrere Threads zu verteilen. Auf einem Zwei-Kern-Rechner setzen wir dies auf "+ 2 +".

  • + -P +: Zeigt den Fortschritt und die Metriken alle + 60 + Sekunden an.

  • + -T +: Führen Sie den Benchmark für + 600 + Sekunden (10 Minuten) aus. Um konsistente und reproduzierbare Ergebnisse zu erzielen, ist es wichtig, dass Sie den Benchmark mehrere Minuten oder einen Prüfpunktzyklus lang ausführen.

Wir geben außerdem an, dass wir den Benchmark für die zuvor erstellte und aufgefüllte "+ Benchmark +" - Datenbank ausführen möchten.

Führen Sie den folgenden vollständigen Befehl + pgbench + aus:

pgbench -h  -p 25060 -U doadmin -c 50 -j 2 -P 60 -T 600 benchmark

Drücken Sie + ENTER + und geben Sie das Passwort für den Benutzer + doadmin + ein, um den Test auszuführen. Sie sollten eine Ausgabe ähnlich der folgenden sehen (die Ergebnisse hängen von den Spezifikationen Ihres PostgreSQL-Clusters ab):

Outputstarting vacuum...end.
progress: 60.0 s, 157.4 tps, lat 282.988 ms stddev 40.261
progress: 120.0 s, 176.2 tps, lat 283.726 ms stddev 38.722
progress: 180.0 s, 167.4 tps, lat 298.663 ms stddev 238.124
progress: 240.0 s, 178.9 tps, lat 279.564 ms stddev 43.619
progress: 300.0 s, 178.5 tps, lat 280.016 ms stddev 43.235
progress: 360.0 s, 178.8 tps, lat 279.737 ms stddev 43.307
progress: 420.0 s, 179.3 tps, lat 278.837 ms stddev 43.783
progress: 480.0 s, 178.5 tps, lat 280.203 ms stddev 43.921
progress: 540.0 s, 180.0 tps, lat 277.816 ms stddev 43.742
progress: 600.0 s, 178.5 tps, lat 280.044 ms stddev 43.705
transaction type: <builtin: TPC-B (sort of)>
scaling factor: 150
query mode: simple
number of clients: 50
number of threads: 2
duration: 600 s
number of transactions actually processed: 105256
latency average = 282.039 ms
latency stddev = 84.244 ms
tps = 175.329321 (including connections establishing)
tps = 175.404174 (excluding connections establishing)

Hierbei haben wir beobachtet, dass wir in einem 10-minütigen Durchlauf mit 50 gleichzeitigen Sitzungen 105.256 Transaktionen mit einem Durchsatz von ungefähr 175 Transaktionen pro Sekunde verarbeitet haben.

Führen Sie jetzt denselben Test aus, und verwenden Sie diesmal 150 gleichzeitige Clients. Dieser Wert ist höher als "+ max_connections +" für diese Datenbank, um einen Massenanstieg von Clientverbindungen zu simulieren:

pgbench -h  -p 25060 -U doadmin -c 150 -j 2 -P 60 -T 600 benchmark

Sie sollten eine Ausgabe ähnlich der folgenden sehen:

Outputstarting vacuum...end.
connection to database "pgbench" failed:
FATAL:  remaining connection slots are reserved for non-replication superuser connections
progress: 60.0 s, 182.6 tps, lat 280.069 ms stddev 42.009
progress: 120.0 s, 253.8 tps, lat 295.612 ms stddev 237.448
progress: 180.0 s, 271.3 tps, lat 276.411 ms stddev 40.643
progress: 240.0 s, 273.0 tps, lat 274.653 ms stddev 40.942
progress: 300.0 s, 272.8 tps, lat 274.977 ms stddev 41.660
progress: 360.0 s, 250.0 tps, lat 300.033 ms stddev 282.712
progress: 420.0 s, 272.1 tps, lat 275.614 ms stddev 42.901
progress: 480.0 s, 261.1 tps, lat 287.226 ms stddev 112.499
progress: 540.0 s, 272.5 tps, lat 275.309 ms stddev 41.740
progress: 600.0 s, 271.2 tps, lat 276.585 ms stddev 41.221
transaction type: <builtin: TPC-B (sort of)>
scaling factor: 150
query mode: simple
number of clients: 150
number of threads: 2
duration: 600 s
number of transactions actually processed: 154892
latency average = 281.421 ms
latency stddev = 125.929 ms
tps = 257.994941 (including connections establishing)
tps = 258.049251 (excluding connections establishing)

Beachten Sie den Fehler "+ FATAL ", der darauf hinweist, dass " pgbench " den Grenzwert für 100 Verbindungen erreicht hat, der durch " max_connections +" festgelegt wurde, was zu einer abgelehnten Verbindung führt. Der Test konnte mit einer TPS von ca. 257 noch abgeschlossen werden.

An dieser Stelle können wir untersuchen, wie ein Verbindungspool den Durchsatz unserer Datenbank potenziell verbessern kann.

Schritt 3 - Erstellen und Testen eines Verbindungspools

In diesem Schritt erstellen wir einen Verbindungspool und führen den vorherigen "+ pgbench +" - Test erneut aus, um festzustellen, ob wir den Durchsatz unserer Datenbank verbessern können.

Im Allgemeinen werden die Parameter "+ max_connections " und "Connection Pool" so abgestimmt, dass die Datenbank maximal ausgelastet ist. Da jedoch " max_connections +" in DigitalOcean Managed Databases vom Benutzer weg abstrahiert ist, sind unsere wichtigsten Hebel hier die Einstellungen für den Verbindungspool * Mode * und * Size *.

Zunächst erstellen wir einen Verbindungspool im Transaktionsmodus, in dem alle verfügbaren Back-End-Verbindungen geöffnet bleiben.

Navigieren Sie in der Systemsteuerung zu "Datenbanken" und klicken Sie auf Ihren PostgreSQL-Cluster. Klicken Sie von hier aus in "Verbindungspools". Klicken Sie anschließend auf * Verbindungspool erstellen *.

Geben Sie im angezeigten Konfigurationsfenster die folgenden Werte ein:

image: https://assets.digitalocean.com/articles/managed_db_pools/connection_pool_full.png [Konfigurationswerte für den Verbindungspool]

Hier benennen wir unseren Verbindungspool * test-pool * und verwenden ihn mit der * benchmark * -Datenbank. Unser Datenbankbenutzer ist * doadmin * und wir setzen den Verbindungspool auf den Modus * Transaction *. Wir erinnern uns, dass für einen verwalteten Datenbankcluster mit 4 GB RAM 97 Datenbankverbindungen verfügbar sind. Konfigurieren Sie den Pool dementsprechend so, dass 97 Datenbankverbindungen geöffnet bleiben.

Wenn Sie fertig sind, klicken Sie auf "Pool erstellen".

Sie sollten jetzt diesen Pool in der Systemsteuerung sehen:

image: https: //assets.digitalocean.com/articles/managed_db_pools/connection_pool_ui.png [Verbindungspool in der Systemsteuerung]

Klicken Sie auf * Connection Details *, um die URI abzurufen. Es sollte ungefähr so ​​aussehen

postgres://doadmin:@:/test-pool?sslmode=require

Sie sollten hier einen anderen Port und möglicherweise einen anderen Endpunkt- und Datenbanknamen feststellen, der dem Poolnamen "+ test-pool +" entspricht.

Nachdem wir den "+ test-pool " - Verbindungspool erstellt haben, können wir den oben ausgeführten " pgbench +" - Test erneut ausführen.

Führen Sie + pgbench + erneut aus

Führen Sie auf Ihrem Clientcomputer den folgenden Befehl + pgbench + (mit 150 gleichzeitigen Clients) aus, und stellen Sie sicher, dass Sie die hervorgehobenen Werte durch die Werte in Ihrem Verbindungspool-URI ersetzen:

pgbench -h  -p  -U doadmin -c 150 -j 2 -P 60 -T 600 test-pool

Hier verwenden wir wieder 150 gleichzeitige Clients, führen den Test über 2 Threads aus, drucken den Fortschritt alle 60 Sekunden und führen den Test 600 Sekunden lang aus. Wir setzen den Datenbanknamen auf "+ test-pool +", den Namen des Verbindungspools.

Nach Abschluss des Tests sollte eine Ausgabe ähnlich der folgenden angezeigt werden (beachten Sie, dass diese Ergebnisse abhängig von den Spezifikationen Ihres Datenbankknotens variieren):

Outputstarting vacuum...end.
progress: 60.0 s, 240.0 tps, lat 425.251 ms stddev 59.773
progress: 120.0 s, 350.0 tps, lat 428.647 ms stddev 57.084
progress: 180.0 s, 340.3 tps, lat 440.680 ms stddev 313.631
progress: 240.0 s, 364.9 tps, lat 411.083 ms stddev 61.106
progress: 300.0 s, 366.5 tps, lat 409.367 ms stddev 60.165
progress: 360.0 s, 362.5 tps, lat 413.750 ms stddev 59.005
progress: 420.0 s, 359.5 tps, lat 417.292 ms stddev 60.395
progress: 480.0 s, 363.8 tps, lat 412.130 ms stddev 60.361
progress: 540.0 s, 351.6 tps, lat 426.661 ms stddev 62.960
progress: 600.0 s, 344.5 tps, lat 435.516 ms stddev 65.182
transaction type: <builtin: TPC-B (sort of)>
scaling factor: 150
query mode: simple
number of clients: 150
number of threads: 2
duration: 600 s
number of transactions actually processed: 206768
latency average = 421.719 ms
latency stddev = 114.676 ms
tps = 344.240797 (including connections establishing)
tps = 344.385646 (excluding connections establishing)

Beachten Sie hier, dass wir den Durchsatz unserer Datenbank von 257 TPS auf 344 TPS bei 150 gleichzeitigen Verbindungen steigern konnten (eine Steigerung von 33%) und nicht gegen das Limit "+ max_connections +" gelaufen sind, das wir zuvor ohne einen Verbindungspool erreicht haben. Durch Platzieren eines Verbindungspools vor der Datenbank können wir Verbindungsabbrüche vermeiden und den Datenbankdurchsatz in einer Umgebung mit einer großen Anzahl gleichzeitiger Verbindungen erheblich steigern.

Wenn Sie denselben Test ausführen, jedoch mit einem "+ -c +" - Wert von 50 (unter Angabe einer geringeren Anzahl von Clients), werden die Vorteile der Verwendung eines Verbindungspools weniger deutlich:

Outputstarting vacuum...end.
progress: 60.0 s, 154.0 tps, lat 290.592 ms stddev 35.530
progress: 120.0 s, 162.7 tps, lat 307.168 ms stddev 241.003
progress: 180.0 s, 172.0 tps, lat 290.678 ms stddev 36.225
progress: 240.0 s, 172.4 tps, lat 290.169 ms stddev 37.603
progress: 300.0 s, 177.8 tps, lat 281.214 ms stddev 35.365
progress: 360.0 s, 177.7 tps, lat 281.402 ms stddev 35.227
progress: 420.0 s, 174.5 tps, lat 286.404 ms stddev 34.797
progress: 480.0 s, 176.1 tps, lat 284.107 ms stddev 36.540
progress: 540.0 s, 173.1 tps, lat 288.771 ms stddev 38.059
progress: 600.0 s, 174.5 tps, lat 286.508 ms stddev 59.941
transaction type: <builtin: TPC-B (sort of)>
scaling factor: 150
query mode: simple
number of clients: 50
number of threads: 2
duration: 600 s
number of transactions actually processed: 102938
latency average = 288.509 ms
latency stddev = 83.503 ms
tps = 171.482966 (including connections establishing)
tps = 171.553434 (excluding connections establishing)

Hier sehen wir, dass wir den Durchsatz durch die Verwendung eines Verbindungspools nicht steigern konnten. Unser Durchsatz ging von 175 TPS auf 171 TPS zurück.

Obwohl in diesem Handbuch "+ pgbench +" mit dem integrierten Benchmark-Datensatz verwendet wird, ist der beste Test für die Bestimmung, ob ein Verbindungspool verwendet werden soll, eine Benchmark-Last, die die Produktionslast Ihrer Datenbank genau anhand der Produktionsdaten darstellt. Das Erstellen von benutzerdefinierten Benchmarking-Skripten und -Daten würde den Rahmen dieses Handbuchs sprengen. Weitere Informationen finden Sie in der offiziellen pgbench documentation.

Fazit

Das Verbindungspooling von DigitalOcean Managed Databases ist eine leistungsstarke Funktion, mit der Sie schnell zusätzliche Leistung aus Ihrer Datenbank herausholen können. Zusammen mit anderen Techniken wie Replikation, Caching und Sharding können Sie mithilfe des Verbindungspools die Datenbankebene skalieren, um ein noch größeres Anforderungsvolumen zu verarbeiten.

In diesem Handbuch haben wir uns auf ein simples und synthetisches Testszenario konzentriert, das das in PostgreSQL integrierte Benchmarking-Tool "+ pgbench +" und den Standard-Benchmark-Test verwendet. In jedem Produktionsszenario sollten Sie Benchmarks mit den tatsächlichen Produktionsdaten durchführen und gleichzeitig die Produktionslast simulieren. Auf diese Weise können Sie Ihre Datenbank auf Ihr bestimmtes Verwendungsmuster abstimmen.

Neben + pgbench + gibt es noch andere Tools zum Benchmarking und Laden Ihrer Datenbank. Ein solches von Percona entwickeltes Tool ist sysbench-tpcc. Ein weiteres Beispiel ist das JMeter von Apache, mit dem Testdatenbanken sowie Webanwendungen geladen werden können.

Weitere Informationen zu DigitalOcean Managed Databases finden Sie in der Dokumentation zu Managed Databases product. Weitere Informationen zu Sharding, einer weiteren nützlichen Skalierungstechnik, finden Sie unter Understanding Database Sharding.

Verweise

Related