Cloner le dépôt

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

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

Démarrage rapide basé sur le travail de Pavel Zotov (Moscou). Questions sur le test lui-même : [email protected]. Support IBSurgeon : [email protected].

1. Prérequis

Sur l'hôte qui exécutera les sessions ISQL, installez un client Firebird et assurez-vous que ces binaires sont disponibles :

• isql (sur certains paquets POSIX : isql-fb)
• fbsvcmgr

2. Choisir et copier un fichier de configuration

Dans le dossier src, choisissez la configuration par défaut qui correspond à votre version majeure de Firebird et à votre système d'exploitation, puis copiez-la sans le suffixe .default.

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

3. Paramètres importants

Modifiez la configuration copiée. Portez une attention particulière à :

• fbc - chemin vers isql sur la machine qui lance les sessions
• clu - nom de binaire ISQL non standard facultatif (par ex. isql-fb sur les paquets POSIX)
• dbnm - chemin complet et nom de fichier de la base de données sur le serveur (ASCII uniquement ; pas un alias si vous voulez que le script la crée)
• host, port, usr, pwd - paramètres de connexion
• tmpdir - répertoire pour les journaux ISQL et les fichiers de test temporaires
• init_docs - documents à créer avant la charge de travail mesurée (essayez 3000-5000 d'abord)
• warm_time / test_time - phases d'échauffement et de mesure, en minutes
• sleep_min / sleep_max - pause entre les transactions (définissez sleep_max à 0 pour désactiver les pauses)
• sleep_ddl - UDF facultatif pour les pauses (préféré au sleep / cscript du shell) ; binaires sous util/udf64/
• wait_for_copy - pause après l'initialisation pour que vous puissiez prendre un instantané de la base avant l'échauffement/la mesure (utile pour des exécutions répétées)

Après l'initialisation, le test exécute l'échauffement pendant warm_time minutes, puis mesure pendant test_time minutes.

4. Conseils Windows et firebird.conf

Excluez l'analyse antivirus / système d'exploitation de tmpdir et des dossiers temporaires Firebird (FIREBIRD_TMP / TMP / TEMP, et TempDirectories dans firebird.conf). Aligner FIREBIRD_TMP avec TempDirectories réduit les ralentissements sous de nombreuses sessions ISQL.

Augmentez au moins :

• DefaultDbCachePages
• LockHashSlots
• LockMemSize
• FileSystemCacheThreshold - doit être défini explicitement et supérieur à DefaultDbCachePages (le test rejette une valeur manquante/commentée, sauf certaines dispositions de paquets POSIX)

Visez environ 25 % de la RAM pour le cache de pages. Ne définissez pas DefaultDbCachePages au-dessus de 2048 pour Classic / SuperClassic. La taille de page est codée en dur à 8192.

Exemple de charge moyenne (~100 sessions) :

Pour des configurations prêtes à l'emploi, consultez le Calculateur de configuration et les configurations de référence.

5. Exécuter le test

Ouvrez un shell, placez-vous dans src, et exécutez :

1run_oltp_emul <FbMajor> <NumSessions> [nostop]

• FbMajor - 25, 30 ou 40 pour Firebird 2.5 / 3.0 / 4.0
• NumSessions - nombre de sessions ISQL à lancer
• nostop - facultatif ; ignore les pauses interactives (utile depuis un planificateur)

Si le fichier de base de données n'existe pas et que dbnm est un chemin complet (pas un alias), le script peut le créer. Les bases précédentes incomplètes ou vides sont recréées si nécessaire.

6. Rapports et arrêt

Après l'échauffement + le temps de mesure, les sessions s'arrêtent automatiquement. La première session ISQL écrit le rapport final sous tmpdir. Avec make_html = 1 sur Windows, un rapport HTML est également produit (plus lent).

La dénomination des rapports dépend de file_name_with_test_params :

• Commenté (par défaut) - par ex. oltp**.report.txt
• regular - noms horodatés adaptés à la navigation de nombreuses exécutions dans un listing de dossier
• benchmark - noms adaptés à la comparaison de paramètres/variantes DDL

Les rapports incluent l'architecture et les paramètres, les performances globales et par intervalle (CNT_OK_PER_MINUTE / AVG_TIMES_PER_MINUTE), les détails de surveillance facultatifs, les exceptions, les statistiques de base de données, les ratios de version/enregistrement, la validation des tables modifiées, et un diff avant/après de firebird.log.

Vous pouvez également interroger :

select * from srv_mon_perf_dynamic;
select * from srv_mon_perf_total;

Ce que modélise la charge de travail

Le scénario suit des documents métier de type service automobile :

1. Commandes client (ou internes) de pièces
2. Commandes combinées et envoyées à un fournisseur
3. Facture fournisseur (totale ou partielle)
4. Réception de stock ; pièces commandées par le client réservées
5. Ventes et sorties de stock
6. Annulations possibles à plusieurs étapes
7. Paiements partiels/totaux et annulations affectant les soldes
8. La première session produit les rapports de performance, d'exceptions, de statistiques et de validation