Lenteur Firebird

[mika]

Bonjour

j'ai développé une appli en Delphi 7 avec interbase 6.0 et les composant Interbase. Le programme a été installé sur XP. Or bp de lenteur. j'ai donc mis Firebird sur le serveur et la lenteur au démarrage n'existe plus.

par contre lorsque je fait un table1.last, cela met un eternité.

Savez vous à quoi cela peut être du

[qi130]

Passons sur le 1er point, déjà identifié...


Pour le second, ça veut dire quoi une éternité ?

Ca dure, ça dure, mais c'est peut-être normal, comment veux-tu qu'on réponde sans plus de détails ?
- taille de la table ? et des colonnes qui la composent ?
- serveur dédié ?

[mika]

Désolé pour le manque d'info

La taille de la table 9000 enregistrement trié par un index primaire
Le fait de faire un last met prés de 30 à 40 secondes
Le serveur n'est pas dédié

[kase74]

Salut !
9000 enreg, c'est rien !

Est ce que tu n'aurait pas implemente des evenements comme AfterOpen, AfterRefresh, AfterScroll, AfterGetRecord ou autre ? (je ne les ai plus tous en tete)

Est ce que cette table est liee par une relation maitre detail ?

De toutes facon, ce qu'il y a de sur, c'est que ce n'est pas normal.
J'ai eu un probleme similaire : le probleme etait que dans AfterInsert/Update/Delete/Refresh/Scroll d'une de mes tables, je faisait un Close/Open de la table Maitre, ce qui mettait un temps monstrueux. Le probleme a ete resolu en faisant juste un RefreshRecord de cette table maitre.

[mika]

Je suis tout à fait d'accord avec vous 9000 enregistrement c'est rien.

Voici ce que je fais

Code :

1
2
3
4
5
6
IbMatable.filter := 'ETATAPPEL = 3';
 ibmatable.filtered := true;
 ibmatable.first;
 ibmatable.last; // ici 30 à 40 seconde
ou 
ibmatable.locate('NUMAPPEL', Codeappel); // pareil 30 à 40 secondes

Merci de bien vouloir me donner une explication

[hgourvest]

9000 enregistrements ce n'est rien, mais ca dépende de la taille de chaque enregistrement, et malheureusement IBX n'est pas optimisé pour stocker de gros dataset, je te propose d'activer la propriété unidirectionnal ce qui aura pour effet de désactiver le cache des enregistrements parcourus, tu sera alors fixé si le probleme vient de la. D'autre part, on recommande générallement de ne pas utiliser les composants tables et d'utiliser une query à la place.

[kase74]

Bonjour,
J'ajouterai aussi qu'il serait bon de verifier qu'il existe bien un index sur le champ que tu veux filtrer.

Moi j'essaierais la meme requete depuis un DBManager comme IBExpert pour tester si le pb vient de la structure de ma table ou bien de l'implementation dans delphi.

[WebPac]

Est ce que le serveur ne gèrerait pas l'hyperthreading ou n'aurrait-il pas plusieurs processeurs ?

Si c'est le cas :
http://thierry-laborde.developpez.com/articles/interbase6/

[Neilos]

J'ai complètement craqué moi....désolé je voulais faire un nouveau post et je me suis loupé :S

[mika]

Re bonjour

Effectivement j'ai pris connaissance du topics et j'ai fait exactement ce qui et dit dessus, mais la lenteur existe toujours, surtout lors d'un table.locate. Je pense que je vais sans doute passer par des tibQuery, mais pour le moment je n'ai pas le temps de modifier cette appli alors je laisse tel quel, mais j'aimerais qd même rendre plus rapide mon locate.

A+

merci encore

[jean-jacques varvenne]

le dispositif contenu dans delphi "locate" et très long à cause du fait qu'il lit chaque enregistrement pour en analyser le contenu.

dans les faits, ton programme rapatrie à grand coup de réseau chaque enregistrement de la table, fait une comparaison et passe au suivant...

utilise plutôt une requête du genre: select * from matable where containing 'ce que tu recherche'

c'est une approche déjà plus valable, mais restant lente tout de même car elle n'utilise pas les index, mais infiniment plus performante que "locate"

[mika]

Bonjour

Je vous remercie tous pour vos réponses. J'ai pu effectivement réduire ma lenteur à certains moment.

Ce qui faudrait maintenant c'est que j'arrive à pouvoir modifier mon enregistrement de ma requete en utilisant le tibupdatesql.

Merci encore