Repository klonen

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

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

Schnellstart basierend auf der Arbeit von Pavel Zotov (Moskau). Fragen zum Test selbst: [email protected]. IBSurgeon-Support: [email protected].

1. Voraussetzungen

Installieren Sie auf dem Host, der die ISQL-Sitzungen ausführt, einen Firebird-Client und stellen Sie sicher, dass diese Binärdateien verfügbar sind:

• isql (bei einigen POSIX-Paketen: isql-fb)
• fbsvcmgr

2. Konfigurationsdatei auswählen und kopieren

Wählen Sie im Ordner src die Standardkonfiguration aus, die zu Ihrer Firebird-Hauptversion und Ihrem Betriebssystem passt, und kopieren Sie sie ohne das Suffix .default.

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

3. Wichtige Einstellungen

Bearbeiten Sie die kopierte Konfiguration. Achten Sie besonders auf:

• fbc - Pfad zu isql auf dem Rechner, der die Sitzungen startet
• clu - optionaler nicht standardmäßiger ISQL-Binärname (z. B. isql-fb bei POSIX-Paketen)
• dbnm - vollständiger Pfad und Dateiname der Datenbank auf dem Server (nur ASCII; kein Alias, wenn das Skript die Datenbank erstellen soll)
• host, port, usr, pwd - Verbindungsparameter
• tmpdir - Verzeichnis für ISQL-Protokolle und temporäre Testdateien
• init_docs - Dokumente, die vor der gemessenen Arbeitslast erstellt werden sollen (zuerst 3000-5000 versuchen)
• warm_time / test_time - Aufwärm- und Messphasen in Minuten
• sleep_min / sleep_max - Pause zwischen Transaktionen (setzen Sie sleep_max auf 0, um Pausen zu deaktivieren)
• sleep_ddl - optionale UDF für Pausen (bevorzugt gegenüber Shell-sleep / cscript); Binärdateien unter util/udf64/
• wait_for_copy - Pause nach der Initialisierung, damit Sie die Datenbank vor Aufwärmen/Messung sichern können (nützlich für wiederholte Läufe)

Nach der Initialisierung führt der Test warm_time Minuten Aufwärmphase und dann test_time Minuten Messphase durch.

4. Windows- und firebird.conf-Tipps

Schließen Sie Antiviren-/Betriebssystem-Scans von tmpdir und von Firebird-Temp-Ordnern aus (FIREBIRD_TMP / TMP / TEMP und TempDirectories in firebird.conf). Die Angleichung von FIREBIRD_TMP an TempDirectories reduziert Verlangsamungen bei vielen ISQL-Sitzungen.

Erhöhen Sie mindestens:

• DefaultDbCachePages
• LockHashSlots
• LockMemSize
• FileSystemCacheThreshold - muss explizit gesetzt und größer als DefaultDbCachePages sein (der Test lehnt einen fehlenden/auskommentierten Wert ab, außer bei einigen POSIX-Paketlayouts)

Zielen Sie auf etwa 25 % des Arbeitsspeichers für den Seitenpuffer ab. Setzen Sie DefaultDbCachePages für Classic / SuperClassic nicht über 2048. Die Seitengröße ist fest auf 8192 codiert.

Beispiel für mittlere Last (~100 Sitzungen):

Für vorgefertigte Konfigurationen siehe den Konfigurationsrechner und Referenzkonfigurationen.

5. Test ausführen

Öffnen Sie eine Shell, wechseln Sie zu src und führen Sie aus:

1run_oltp_emul <FbMajor> <NumSessions> [nostop]

• FbMajor - 25, 30 oder 40 für Firebird 2.5 / 3.0 / 4.0
• NumSessions - Anzahl der zu startenden ISQL-Sitzungen
• nostop - optional; überspringt interaktive Pausen (nützlich für Zeitplaner)

Wenn die Datenbankdatei nicht existiert und dbnm ein vollständiger Pfad (kein Alias) ist, kann das Skript sie erstellen. Unvollständige oder leere frühere Datenbanken werden bei Bedarf neu erstellt.

6. Berichte und Beenden

Nach Aufwärm- + Messzeit stoppen die Sitzungen automatisch. Die erste ISQL-Sitzung schreibt den Abschlussbericht unter tmpdir. Mit make_html = 1 unter Windows wird auch ein HTML-Bericht erstellt (langsamer).

Die Benennung der Berichte hängt von file_name_with_test_params ab:

• Auskommentiert (Standard) - z. B. oltp**.report.txt
• regular - Zeitstempelnamen, geeignet zum Durchsuchen vieler Läufe in einer Ordnerliste
• benchmark - Namen, die zum Vergleichen von Einstellungen/DDL-Varianten geeignet sind

Die Berichte enthalten Architektur und Einstellungen, Gesamt- und Intervall-Leistung (CNT_OK_PER_MINUTE / AVG_TIMES_PER_MINUTE), optionale Überwachungsdetails, Ausnahmen, Datenbankstatistiken, Versions-/Datensatzverhältnisse, Validierung für geänderte Tabellen und einen firebird.log-Vorher/Nachher-Vergleich.

Sie können auch abfragen:

select * from srv_mon_perf_dynamic;
select * from srv_mon_perf_total;

Was die Arbeitslast modelliert

Das Szenario folgt Geschäftsdokumenten im Autoservice-Stil:

1. Kunden- (oder interne) Bestellungen für Teile
2. Bestellungen werden zusammengefasst und an einen Lieferanten gesendet
3. Lieferantenrechnung (vollständig oder teilweise)
4. Wareneingang; kundenbestellte Teile werden reserviert
5. Verkäufe und Lagerabschreibungen
6. Stornierungen sind in mehreren Schritten möglich
7. Teil-/Vollzahlungen und Stornierungen, die Salden beeinflussen
8. Die erste Sitzung erstellt Leistungs-, Ausnahme-, Statistik- und Validierungsberichte