L'essenziale
pgbench (strumento PostgreSQL ufficiale, carico di lavoro vicino a TPC-B) e sysbench-tpcc (carico di lavoro TPC-C più rappresentativo di un carico transazionale reale) vengono entrambi eseguiti direttamente contro la stringa di connessione Postgres 16 standard del tuo progetto Aurabase: nessuna API proprietaria da bypassare. Questo tutorial mostra gli ordini effettivi e dove finisce ciò che una cifra GST può legittimamente dimostrare.
pgbench per semplicità, sysbench-tpcc per realismo
pgbench è distribuito con PostgreSQL stesso: nessuna installazione separata sul client se disponi già degli strumenti client Postgres. Il suo carico di lavoro predefinito riproduce un carico vicino allo storico benchmark TPC-B: semplice, veloce da avviare, utile per un primo segnale.
sysbench è uno strumento di benchmark più generale, con un plugin sysbench-tpcc che replica il carico di lavoro TPC-C: un mix di transazioni rappresentative di una vera applicazione OLTP (ordini, pagamenti, inventario), più vicino a ciò che il tuo backend Aurabase gestisce in produzione rispetto al carico di lavoro generico pgbench.
Recupera la stringa di connessione e crea una base di test dedicata
1
Recupera la stringa di connessione dalla dashboard di Aurabase
Sezione database del tuo progetto, formato standard postgresql://user:password@host:5432/dbname.
2
Crea una base di test separata, mai la tua base di produzione
psql "$AURABASE_CONN" -c "CREA DATABASE bench_test;"
pgbench e sysbench-tpcc creano, popolano e modificano tabelle. Utilizza sempre una base dedicata, mai uno schema che serva traffico reale.
Inizializzare e avviare una prima esecuzione
1
Inizializzare il set di dati
pgbench -i -s 10 "postgresql://user:pass@host:5432/bench_test" # -s 10 = fattore di scala (10 × 100.000 righe in pgbench_accounts)
2
Esegui una corsa di 60 secondi, 10 clienti concorrenti
pgbench -c 10 -j 2 -T 60 -P 5 "postgresql://user:pass@host:5432/bench_test" # -c = client simultanei · -j = thread · -T = durata in secondi · -P = report ogni 5 s
3
Leggi il risultato
pgbench visualizza un tps (transazioni al secondo) alla fine dell'esecuzione, con e senza il tempo di connessione. Nota il fattore di scala, il numero di clienti e la durata per esecuzione: senza questi tre parametri, il numero da solo non significa nulla.
Un carico di lavoro transazionale più rappresentativo
1
Installa sysbench e il plugin tpcc
git clone https://github.com/Percona-Lab/sysbench-tpcc.git # segui il README del repository per la compilazione del plugin
2
Preparare il set di dati TPC-C
./tpcc.lua --pgsql-host=host --pgsql-user=utente --pgsql-password=pass \ --pgsql-db=bench_test --warehouses=10 prepara
3
Inizia la corsa
./tpcc.lua --pgsql-host=host --pgsql-user=utente --pgsql-password=pass \ --pgsql-db=bench_test --warehouses=10 --time=300 --threads=16 --report-interval=10 esegui
Una guida all'ottimizzazione di sysbench-tpcc dedicata a PostgreSQL è stata pubblicata da Percona nel maggio 2026, utile per ottimizzare shared_buffers e work_mem prima di eseguire un'esecuzione rappresentativa.
Ciò che la cifra GST da sola non dimostra
Il tps dipende dal fattore di scala, dal numero di client simultanei, dall'hardware sottostante e dalle impostazioni Postgres attive al momento dell'esecuzione. Due cifre temporali ottenute con parametri diversi non sono confrontabili, nemmeno sullo stesso database.
Affinché il risultato possa fungere da riferimento riproducibile, documentare sistematicamente: versione di Postgres, fattore di scala, numero di client/thread, durata dell'esecuzione e configurazione postgresql.conf effettiva. Consulta la nostra metodologia di benchmark completa per il protocollo che applichiamo prima di pubblicare una figura.
Ottimizzazione di Postgres prima di riavviare una corsa
Un'esecuzione di benchmark spesso rivela un collo di bottiglia prima di qualsiasi aggiustamento: connessioni saturate, autovacuum ritardato, indice mancante. La nostra lista di controllo per l'ottimizzazione di Postgres in produzione e il nostro articolo sul dimensionamento max_connections trattano le impostazioni da verificare prima di riavviare un'esecuzione.