Discussion :

[lio33]

Bonjour.

Je cherche à faire des tests de performances sur une petite base de données FIREBIRD. Pour cela j'ai crée une procédure stockée que j'appelle plusieurs fois par secondes ( nombre d'appels par seconde ajustables ). L'Application est développée en C souS Labwindows/CVI en utilisant le SQL TOOLKIT de National Instrument via driver ODBC Firebird.

Tout marche OK, sauf qu'a chaque appel de ma PS je vois que la mémoire utilisée croit régulièrement (40Ko environ par appel de PS). Dés que je dépasse la taille de ma RAM cela commence à swapper sur disque et là bien sûr les performances s'écroulent.

Dés que je me déconnecte de la base de données depuis mon application je vois la mémoire qui se libère.

Le principe de mon appli est le suivant :
1) Connexion base de données
2) déclenchement des appels périodiques d'une procédure stockée ( je laisse tourner un temps indéfini ... ) ==> Mémoire utilisée augmente
3) arrêt des appels à la procédure stockée ==> mémoire utilisée stabilisée
4) déconnexion ==> mémoire se libère

Usuellement, lorsqu'une application exploite une base de données, effectue-t-elle une connexion, déconnexion à chaque fois qu'elle fait une requête vers la BDD, ou ne fait-elle qu'une seule connexion, puis traitement de plusieurs requêtes et finalement déconnexion ?

J'ai tenté la première solution pour le principe mais les peformances sont alors trés réduites.

J'aimerai avoir votre avis là-dessus.

[qi130]

S'agissant d'une appli avec inter-actions fortes (=fréquentes) entre le client et le serveur, il est préférable de n'avoir qu'une connexion.

[lio33]

Bonjour.

C'est effectivement ce que réalise mon application de test.
En fait le code utilisé pour l'appel à la procédure stockée réserve de la mémoire et ne la libère pas en final. Je l'ai optimisé car je répétais des instructions qui n'étaient pas nécessaire mais maintenant il est assez réduit.

Voici ce que cela donne si jamais cela interpelle un auditeur de ce forum :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
/* Set the parameters */
resCode = DBSetParamInt (hstmt, 1, valeurS);
resCode = DBSetParamInt (hstmt, 2, valeurE);
resCode = DBSetParamInt (hstmt, 3, idUTC);
resCode = DBSetParamInt (hstmt, 4, idACCES);
resCode = DBSetParamChar (hstmt, 5, mapDateTime, "yyyy/m/d h:i:s");
/* Execute the statement. */
resCode = DBExecutePreparedSQL (hstmt);
resCode = DBClosePreparedSQL (hstmt);

[lio33]

Problème résolu, ci-joint code :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
resCode = DBSetAttributeDefault (hdbc, ATTR_DB_COMMAND_TYPE,DB_COMMAND_STORED_PROC);
hstmt = DBPrepareSQL (hdbc, "PR_MAJ_PASSAGE");
resCode = DBSetAttributeDefault (hdbc, ATTR_DB_COMMAND_TYPE,DB_COMMAND_UNKNOWN);
/* Refresh the parameters from the stored procedure. */
resCode = DBRefreshParams (hstmt);
 
/* Set the input parameters  */
resCode = DBSetParamInt (hstmt, 1, valeur1);
resCode = DBSetParamInt (hstmt, 2, valeur2);
resCode = DBSetParamInt (hstmt, 3, valuer3);
 
/* Execute the statement. */
resCode = DBExecutePreparedSQL (hstmt);
 
/* Pour libérer des ressources proprement */
resCode = DBDeactivateSQL(hstmt);

Désormais la mémoire reste stable !

[Andry]

Effectivement,
La préparation d'un ordre SQL

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
hstmt = DBPrepareSQL (hdbc, "PR_MAJ_PASSAGE");

requert du ressource que tu dois desaloué des que tu as fini ton traitement.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
resCode = DBDeactivateSQL(hstmt);

Avec Delphi, l'appel à Prepare doit s'utiliser avec l'appel à Unprepare à la fin du traitement pour liberer la mémoire sinon on risque de saturer la mémoire.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
try
 Query.prepare
// Traitement
 
finally
  Query.unprepare

A+