Clona il repository

git clone --config core.autocrlf=true https://github.com/FirebirdSQL/oltp-emul

git clone --config core.autocrlf=false https://github.com/FirebirdSQL/oltp-emul

Avvio rapido basato sul lavoro di Pavel Zotov (Mosca). Domande sul test stesso: [email protected]. Supporto IBSurgeon: [email protected].

1. Prerequisiti

Sull'host che eseguirà le sessioni ISQL, installa un client Firebird e assicurati che questi eseguibili siano disponibili:

• isql (su alcuni pacchetti POSIX: isql-fb)
• fbsvcmgr

2. Scegli e copia un file di configurazione

Nella cartella src, scegli la configurazione predefinita che corrisponde alla tua versione principale di Firebird e al tuo sistema operativo, quindi copiala senza il suffisso .default.

# Windows
copy .\oltp30_config.win.default .\oltp30_config.win
Linux
cp ./oltp30_config.nix.default ./oltp30_config.nix

3. Impostazioni importanti

Modifica la configurazione copiata. Presta particolare attenzione a:

• fbc - percorso di isql sulla macchina che avvia le sessioni
• clu - nome binario ISQL non standard opzionale (es. isql-fb sui pacchetti POSIX)
• dbnm - percorso completo e nome file del database sul server (solo ASCII; non un alias se vuoi che lo script lo crei)
• host, port, usr, pwd - parametri di connessione
• tmpdir - directory per i log ISQL e i file di test temporanei
• init_docs - documenti da creare prima del carico di lavoro misurato (prova prima 3000-5000)
• warm_time / test_time - fasi di riscaldamento e misurazione, in minuti
• sleep_min / sleep_max - pausa tra le transazioni (imposta sleep_max a 0 per disabilitare le pause)
• sleep_ddl - UDF opzionale per le pause (preferito rispetto a sleep / cscript della shell); binari in util/udf64/
• wait_for_copy - pausa dopo l'init per poter fare uno snapshot del DB prima di riscaldamento/misurazione (utile per esecuzioni ripetute)

Dopo l'init, il test esegue il riscaldamento per warm_time minuti, quindi misura per test_time minuti.

4. Suggerimenti per Windows e firebird.conf

Escludi la scansione antivirus / di sistema da tmpdir e dalle cartelle temporanee di Firebird (FIREBIRD_TMP / TMP / TEMP e TempDirectories in firebird.conf). Allineare FIREBIRD_TMP con TempDirectories riduce i rallentamenti sotto molte sessioni ISQL.

Aumenta almeno:

• DefaultDbCachePages
• LockHashSlots
• LockMemSize
• FileSystemCacheThreshold - deve essere impostato esplicitamente e maggiore di DefaultDbCachePages (il test rifiuta un valore mancante/commentato, tranne alcune disposizioni di pacchetti POSIX)

Punta a circa il 25% della RAM per la cache delle pagine. Non impostare DefaultDbCachePages sopra 2048 per Classic / SuperClassic. La dimensione della pagina è hardcoded a 8192.

Esempio di carico medio (~100 sessioni):

Per configurazioni già pronte, consulta il Calcolatore di configurazione e le configurazioni di riferimento.

5. Esegui il test

Apri una shell, vai in src ed esegui:

1run_oltp_emul <FbMajor> <NumSessions> [nostop]

• FbMajor - 25, 30 o 40 per Firebird 2.5 / 3.0 / 4.0
• NumSessions - numero di sessioni ISQL da avviare
• nostop - opzionale; salta le pause interattive (utile da un pianificatore)

Se il file del database non esiste e dbnm è un percorso completo (non un alias), lo script può crearlo. I database precedenti incompleti o vuoti vengono ricreati secondo necessità.

6. Report e arresto

Dopo il tempo di riscaldamento + misurazione, le sessioni si fermano automaticamente. La prima sessione ISQL scrive il report finale in tmpdir. Con make_html = 1 su Windows, viene prodotto anche un report HTML (più lento).

La denominazione del report dipende da file_name_with_test_params:

• Commentato (predefinito) - es. oltp**.report.txt
• regular - nomi con timestamp adatti alla navigazione di molte esecuzioni in un elenco di cartelle
• benchmark - nomi adatti al confronto di impostazioni/varianti DDL

I report includono architettura e impostazioni, prestazioni complessive e per intervallo (CNT_OK_PER_MINUTE / AVG_TIMES_PER_MINUTE), dettagli di monitoraggio opzionali, eccezioni, statistiche del database, rapporti versione/record, validazione per le tabelle modificate e un diff prima/dopo di firebird.log.

Puoi anche interrogare:

select * from srv_mon_perf_dynamic;
select * from srv_mon_perf_total;

Cosa modella il carico di lavoro

Lo scenario segue documenti aziendali in stile officina automobilistica:

1. Ordini del cliente (o interni) per parti
2. Ordini combinati e inviati a un fornitore
3. Fattura del fornitore (totale o parziale)
4. Ricevimento merce; parti ordinate dal cliente riservate
5. Vendite e scarichi di magazzino
6. Cancellazioni possibili in più fasi
7. Pagamenti parziali/totali e cancellazioni che influiscono sui saldi
8. La prima sessione produce report su prestazioni, eccezioni, statistiche e validazione