De essentie
pgbench (officiële PostgreSQL-tool, werklast dichtbij TPC-B) en sysbench-tpcc (TPC-C-werklast die representatiever is voor een echte transactionele belasting) draaien beide rechtstreeks tegen de standaard Postgres 16-verbindingsreeks van uw Aurabase-project - er is geen eigen API om te omzeilen. Deze tutorial toont de daadwerkelijke bestellingen en waar wat een GST-cijfer legitiem kan bewijzen, eindigt.
pgbench voor eenvoud, sysbench-tpcc voor realisme
pgbench wordt gedistribueerd met PostgreSQL zelf: geen aparte installatie op de client als u al over Postgres-clienttools beschikt. De standaardwerklast reproduceert een belasting die dicht bij de historische TPC-B-benchmark ligt: eenvoudig, snel te starten, handig voor een eerste signaal.
sysbench is een meer algemene benchmarktool, met een sysbench-tpcc-plug-in die de TPC-C-werklast repliceert – een mix van transacties die representatief zijn voor een echte OLTP-applicatie (bestellingen, betalingen, inventaris), en dichter bij wat uw Aurabase-backend tijdens de productie afhandelt dan de generieke pgbench-werklast.
Haal de verbindingsreeks op en maak een speciale testbasis
1
Haal de verbindingsreeks op van het Aurabase-dashboard
Databasegedeelte van uw project, standaard postgresql://user:password@host:5432/dbname-formaat.
2
Creëer een aparte testbasis, nooit uw productiebasis
psql "$AURABASE_CONN" -c "CREËER DATABASE bench_test;"
pgbench en sysbench-tpcc maken, vullen en wijzigen tabellen. Gebruik altijd een speciale basis, nooit een schema dat echt verkeer bedient.
Initialiseer en start een eerste run
1
Initialiseer de gegevensset
pgbench -i -s 10 "postgresql://user:pass@host:5432/bench_test" # -s 10 = schaalfactor (10 × 100.000 rijen in pgbench_accounts)
2
Voer een run van 60 seconden uit, met 10 concurrerende clients
pgbench -c 10 -j 2 -T 60 -P 5 "postgresql://user:pass@host:5432/bench_test" # -c = gelijktijdige clients · -j = threads · -T = duur in seconden · -P = rapporteer elke 5s
3
Lees het resultaat
pgbench geeft aan het einde van de run een tps (transacties per seconde) weer, met en zonder de verbindingstijd. Let op de schaalfactor, het aantal clients en de duur per run – zonder deze drie parameters betekent het aantal alleen niets.
Een meer representatieve transactionele werklast
1
Installeer sysbench en de tpcc-plug-in
git clone https://github.com/Percona-Lab/sysbench-tpcc.git # volg de README van de repository voor het compileren van de plug-in
2
Bereid de TPC-C-gegevensset voor
./tpcc.lua --pgsql-host=host --pgsql-user=gebruiker --pgsql-password=pass \ --pgsql-db=bench_test --warehouses=10 voorbereiden
3
Begin met rennen
./tpcc.lua --pgsql-host=host --pgsql-user=gebruiker --pgsql-password=pass \ --pgsql-db=bench_test --warehouses=10 --time=300 --threads=16 --report-interval=10 run
Een sysbench-tpcc-afstemmingsgids speciaal voor PostgreSQL werd in mei 2026 door Percona gepubliceerd - handig voor het afstemmen van shared_buffers en work_mem voordat een representatieve run wordt uitgevoerd.
Wat een GST-cijfer alleen niet bewijst
De tps is afhankelijk van de schaalfactor, het aantal gelijktijdige clients, de onderliggende hardware en de Postgres-instellingen die actief zijn op het moment van de run. Twee tijdscijfers verkregen met verschillende parameters zijn niet vergelijkbaar, zelfs niet in dezelfde database.
Om ervoor te zorgen dat uw resultaat als reproduceerbare referentie kan dienen, documenteert u systematisch: Postgres-versie, schaalfactor, aantal clients/threads, runduur en de effectieve postgresql.conf-configuratie. Bekijk onze volledige benchmarkmethodologie voor het protocol dat we toepassen voordat we een cijfer publiceren.
Postgres afstemmen voordat u een run opnieuw start
Een benchmarkrun brengt vaak vóór elke aanpassing een knelpunt aan het licht: verzadigde verbindingen, achterblijvend autovacuüm, ontbrekende index. Onze Postgres-tuningchecklist in productie en ons artikel over max_connections-grootte behandelen de instellingen die moeten worden gecontroleerd voordat een run opnieuw wordt gestart.