Discussion :

[Nono23]

Bonjour tout le monde.

J'ai une application Delphi 6 reliée à des bases de données Firebird ou SQL Server via une connexion BDE.

Afin de comparer les diverses configuration de nos clients, nous avons réalisé un petit utilitaire qui nous permet de vérifier la vitesse d'exécution d'une requête SQL. l'utilitaire ajoute et supprime des champs dans une base de données de tests.

J'ai réalisé les tests des SGBD suivants. Tous les tests ont été réalisés pour une configuration locale ainsi qu'en réseau
- Firebird 1.5
- Firebird 2.1
- Firebird 2.5
- SQL Server 2005
- SQL Server 2008

Lorsque j'ai réalisé le test de Firebird 2.5 en réseau j'ai eu une drôle de surprise. J'ai refait le test 3 fois et j'ai des temps d'exécution qui différent énormément :

Test 1 :
- Création des enregistrements : 1h 23m 24s
- Suppression des enregistrements : 57s

Test 2 :
- Création des enregistrements : 1h 3m 5s
- Suppression des enregistrements : 37s

Test 3 :
- Création des enregistrements : 1h 50m 55s
- Suppression des enregistrements : 2m 29s

Je n'ai eu aucun problème avec tous les autres tests des autres SGBD que j'ai également réalisé plusieurs fois. Est-ce que quelqu'un a déjà rencontré ce genre de problème avec Firebird 2.5? y a-t-il une explication?

Environnement de test :
-----------------------
PC Client : Windows 7 pro / 3 Go RAM / Intel XEON 2.53 GHz
PC Server : Windows 2003 SP2 / 3.25 Go RAM / Intel XEON 2.83 GHz
Vitesse de connexion : 100 MBits/s

Merci d'avance

Nono

[makowski]

le BDE est une vieillerie à proscrire absolument

sans une description précise des tests, impossible de répondre

le BDE est une vieillerie à proscrire absolument
le BDE est une vieillerie à proscrire absolument
le BDE est une vieillerie à proscrire absolument
le BDE est une vieillerie à proscrire absolument

[Nono23]

Salut Makowski, merci de ta réponse.

Concernant le BDE, nous sommes en train d'étudier un moyen de se passer de son utilisation mais nous devons faire des essais et comme notre application est assez volumineuse, cela prendra pas mal de temps.

En gros, les tests que j'exécute sont :

Pour la partie ajout :

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
17
18
 
 
Query.SQL.Clear;
Query.SQL.Add('SELECT * FROM MATABLE');
Query.Prepare;
Query.Open;
 
For I:=0 To NBTEST Do
Begin
     Query.Append;
     Query.Edit;
     Query.FieldByName('NO_ID').AsInteger:=I;
     Query.FieldByName('XXX').AsString:='xxx';
//     ...
     Query.Post;
End;
Query.Close;
Query.SQL.Clear;

Pour la suppression :

Code :

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

1
2
3
4
5
6
7
8
 
For I:=0 To NBTEST Do
Begin 
     Query.SQL.Clear;
     Query.SQL.Add('DELETE FROM MATABLE');
     Query.SQL.Add('WHERE NO_ID = '+IntToStr(I));
     Query.ExecSQL;
End;

Et je fais ça sur plusieurs tables différentes.

J'espère que ça t'aidera un peu plus.

Je précise que le test est complètement identique pour tous les essais que j'ai fais sur tous les SGBD

Merci encore

[Cl@udius]

Salut

Le BDE est effectivement obsolète, et s'en passer est certainement le meilleur choix à faire (pour ne pas dire obligatoire). Les perfs ont toujours été médiocre avec le BDE, sans parler de l'absence de gestion des transactions.

Concernant tes tests d'insertion, pas étonnant que les perfs soient mauvaises.
L'utilisation d'une boucle incluant un Post, mais surtout l'utilisation de (multiples) FieldByName, c'est de cette façon que l'on obtient des records de lenteur.

Que donne un gstat -h sur ta base ?

@+

[Nono23]

Hello Cl@udius, Merci de ta réponse.

Mon problème n'est pas la lenteur mais la différence de temps entre deux exécutions du même test. Qu'en penses-tu? Est-ce que ces différences sont normales? (On passe quand même du simple au double et sur les autres SGBD, j'obtiens des résultats qui se tiennent, même avec FB2.5 pour une installation en local).

Je vais essayer gstat et voir ce que ça donne.

merci

[makowski]

à mon avis les données périmées à collecter sont légion avec ce genre de code

donc le réglage du garbage collect influe

ensuite Firebird 2,5 est écrit pour du 64 bits
et est donc plus lent en 32

mais ce genre de test là c'est en gros un benchmark pour mesurer ce que coute une mauvaise gestion des transactions avec Firebird

[Barbibulle]

Bonjour,

1- NBTEST est égal à combien pour les 3 tests mesurés ci dessus ?

2- Combien de champs sont insérés ?

Pour ce qui est des 3 tests, vous les faites dans quelles conditions ?

3- L'un après les autres ou vous remettez une base identique avant ?

Car faire Test1 + Delete + Test2 + Delete + Test3 + delete ne va pas donner les même résultats que Test1 + Delete, puis restaurer la base utilisée pour Test1 avant de faire Test2 etc...

Enfin pour comparer des SGDB sur un simple test d'insertion de masse, il faut avant s'assurer que les conditions initiales des SGBD sont les mêmes (page size, ...)

J'imagine que vous faites des tests avec BDE parce qu'en réalité vous souhaitez le garder. Parce que sinon je ne vois pas trop l'utilité de ces tests.

C'est comme si un magasine d'auto décidait de comparer une Ferrari et une Porshe mais ils n'ont pas d'essence, alors ils décident de les tester avec du gazoil..
Le résultat ne sera pas représentatif d'une utilisation 'normale' et sera complétement différent s'il était fait avec de l'essence et je ne parle pas que des performances mais aussi du classement.

Désolé je suis un peu hors sujet, puisque ca n'explique pas pourquoi avec FB2.5 vous avez des différences de mesure (a moins que vous répondiez à la question 3 ci dessous.)

[Nono23]

Bonjour tout le monde, merci pour vos réponses.

Pour répondre à Brabibulle :
1 : NBTest = 60000
2 : ~150 champs sont enregistrés à chaque itération de la boucle
3. J'ai fait mes tests à la suite sur la même base sans remettre une base identique. Est-ce que cela pourrait-il justifier de si grandes différences?

J'imagine que vous faites des tests avec BDE parce qu'en réalité vous souhaitez le garder

Si si, nous prévoyons de le changer (je ne l'aurais pas dit sinon) mais comme je l'ai déjà dit, notre logiciel est très volumineux et cette opération nécessite beaucoup de tests préalables et un gros travail de "conversion". ça n'est pas une priorité pour l'instant car d'autres demandes de nos clients sont plus importantes.

Voilà Merci encore pour vos réponses

[makowski]

3. J'ai fait mes tests à la suite sur la même base sans remettre une base identique. Est-ce que cela pourrait-il justifier de si grandes différences?

bien evidemment

le BDE est une usine à problème et à création de données périmées dans la base
ce qui ne fait qu'empirer au fur et à mesure
du coup il faut bien nettoyer de temps en temps et c'est là que les pertes de perfs arrivent

encore une fois le BDE est une voie sans issue et déclarée fermée depuis des années
le BDE n'a jamais été bon a autre chose que pour gérer des fichiers Paradox et dBAse et en plus cela doit faire 10 ans maintenant qu'il n'est plus maintenu, et même quand il l'était, c'était déjà une grosse erreur de travailler avec pour autre chose que du paradox ou du dBase

[Barbibulle]

1-

Plus d'une heure pour 60 000 insertions ? C'est plutôt très moche !
Je pensai qu'on parlait de millions.
2- ok
3- Et bien à un moment donné le fichier de la base doit s'agrandir pour pouvoir contenir plus de données (les trous ne sont pas réutilisés donc vos delete ne permettent pas de repartir de la situation initiale).

Rien que pour cette raison les 3 résultats ne peuvent pas être comparables.

A titre de comparaison je me suis créé une table avec 159 champs, l'insertion de 60000 enregistrements me prend moins de 5 minutes. (Volume total des requêtes environ 300Mo).
Et je ne parle même pas de la méthode d'insertion qui utilise les fichiers externes (sinon on tombe à moins de 11 secondes pour le même jeux de données de 60000 insertions)...

Test fait avec un XP core2 duo 2.66GHz 3Go Ram en plus mon serveur de test FB2.5 tourne dans une machine virtuelle (sur ce même PC) sous XP également avec seulement 1Go de Ram.

Le très gros problème de BDE ici c'est qu'il n'utilise qu'une seule transaction pour les 60000 inserts, elle n'est jamais validée. De plus j'imagine que les données sont rechargées en locale après chaque insertion et au lieu d'avoir des insertions régulières dans le temps, le temps pour insérer les derniers enregistrements est simplement catastrophique...

[kaouane]

Pour comparer ou tester des sgbd, il faut attaquer chacun d'eux par des moyens natifs, si non, on va surement faire une oppression pour les uns et faire une illusion pour nous même.