Discussion :

[ciberju]

Bonjour,

Je me suis mis au Windev / Webdev depuis peu.
J'ai donc voulu commencer un petit programme permettant de calculer des statistiques afin de me faire la main.

Or, je me suis retrouvé face à un problème.

Je sélectionne dans une table, via une requête, certaines données.
Afin de traiter mes statistiques, j'essaye de connaître le nombre de lignes contenues dans cette requête.

J'ai donc essayé via divers moyen :

- requête count
- requête sql tapée moi même
- HNbEnr
- HLitPremier et ensuite HNbEnr

Bref, j'ai essayé à peu près tous les moyens proposé sur internet que j'ai trouvé.
Et tous ceux auquels j'ai pensé.

Néanmoins, le temps d'attente est beaucoup trop long.
Ma requête contient 55.000 lignes.
Mais après avoir testé d'autre langage de programmation, je trouve cela étrange que connaître le nombre de lignes d'une requête / table prenne autant de temps.

J'ai également vérifié que ce n'était pas la requête qui prennait du temps.
Pas de problème à ce niveau là, elle s'effectue directement.

Je suis donc coincé, je ne sais plus trop quoi faire afin d'améliorer mes temps de réponse.
Je me vois mal dire au client qu'il doit réduire ses zones de recherche afin d'avoir moins de temps d'attente.

Peut-être pourrez vous m'aiguiller ou me donner des conseils afin d'améliorer mon programme.

Merci d'avance !

[Marco46]

Peut-être pourrez vous m'aiguiller ou me donner des conseils afin d'améliorer mon programme.

Ta BDD est de quel type (HF Classic ? HFCS ? MySQL ? SQLServer ? [...] ?

Si HF Classic, le dossier des données est-il sur un dossier partagé du réseau ou en local ?

Les réponses à ces questions sont fondamentales pour te répondre correctement.

Comment as-tu vérifié la vitesse d'exécution de la requête, pas WDSQL ? Par le debugeur ? Par un outil de gestion de ta BDD ?

[mogwai162]

Peux tu préciser un peu....

Base de donnée ?
Environnement ?
Un bout de code ?

Tu dis que la réquete s'effectue vite mais pas la requete count ? comprend pas

[ciberju]

Désolé pour ces oublis.

Ma base de données est en HF Classic, dossier en local.
Comme je vous ai dit, c'est des test histoire de débuter.

Pour effectuer le test d'exécution, je suis passé par le débugeur.

J'effectue une requête de sélection sur mon fichier d'analyse.
En voici le code SQL :

Code :

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

1
2
3
4
5
6
7
8
 
SELECT 
	Test.Id AS Id,	
	Test.date_Appel AS date_Appel
FROM 
	Test
WHERE 
	Test.date_Appel BETWEEN {SAI_Date_Debut} AND {SAI_Date_Fin}

Et lors du clic sur un bouton, j'effectue l'action suivante :

Code :

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

1
2
3
4
5
6
7
8
 
Nbre est un entier
 
HExécuteRequête(REQ_Sel_Nb_Appel,hRequêteDéfaut,SAI_Date_Debut,SAI_Date_Fin)
 
Nbre = HNbEnr(REQ_Sel_Nb_Appel)
 
info(Nbre)

La première requête : HExécuteRequête s'effectue instantanément
Par contre, lors du HNbEnr, il faut 6-7 secondes avant que le débugeur passe à l'étape suivante.

Pareil si j'effectue une requête SQL de type count à la place du HNbEnr.

Si ce n'était qu'un seul HNbEnr à effectuer, je pourrais encore trouver le temps de réponse passable.
Mais ici, mon but est de faire plusieurs requête de sélection, de connaître la taille de chacunes de ses requêtes afin de les afficher dans ma page.

Je me vois mal attendre 1min devant le pc avant qu'il ait finit des "bêtes calculs".

Voyez-vous des améliorations à apporter ? Une autre manière de faire ?

[mogwai162]

J'aurais tendance a dire que HF Classic, dossier en local c'est pas terrible mais c'est peut être répondre un peu vite aussi.

Mais puisque tu es en test tu peux toujours installer le serveur HF sur ton poste et voir ce que ça donne.

[Marco46]

Tu comptes utiliser ton application en réseau ?

Je sais pas quel est le volume de ta table (tu parlais de 55000 enregs remontés dans ta source de données) mais si 6-7 secondes ça te fais peur, tu vas halluciner quand ta requête mettre 30 minutes à s'exécuter et traiter ton jeu de résultat de 55 000 enregs avec une BDD sur le réseau.

Gagnes du temps, jettes ta base HF et mets-toi à MySQL (ou PostGreSQL), ton count sera instantané.

[vmolines]

Et oublie l'utilisation des ordres H* par la même occasion

[mogwai162]

...tu vas halluciner quand ta requête mettre 30 minutes à s'exécuter et traiter ton jeu de résultat de 55 000 enregs avec une BDD sur le réseau.

Euh... faut pas trop pousser quand même... Si ça met 30 minutes c'est que c'est franchement mal bâti. (programme et/ou base)

[Marco46]

Euh... faut pas trop pousser quand même... Si ça met 30 minutes c'est que c'est franchement mal bâti. (programme et/ou base)

Ben j'ai déjà vu des traitements prendre plusieurs dizaines de minutes parce que les mecs avaient tout dev en HF. Donc pour chaque fichier utilisé -> une boucle TANTQUE PAS HEnDehors().

Pour la requête j'exagère un peu. Mais quelques minutes d'exécutions sans aucun problème. Ca dépends juste du nombre de tables dans la requête et de la taille des index à remonter en local. Si c'est un vieux soft avec 50 clefs composées pour avoir des tris de toutes les sortes, vu la taille de l'index ben ... C'est long ... Je veux dire, j'ai déjà vu des index de plusieurs centaines de MO, même de plusieurs GO avec des bases HF Classic et on compte l'exécution en dizaines de minutes.

Bref ... Je m'égare, on est que jeudi

[=JBO=]

Bonjour,

J'aurais tendance a dire que HF Classic, dossier en local c'est pas terrible mais c'est peut être répondre un peu vite aussi.

Mais puisque tu es en test tu peux toujours installer le serveur HF sur ton poste et voir ce que ça donne.

En terme de vitesse d'exécution des requêtes, je ne crois pas qu'il y ait de différence entre HyperFile Classic utilisé avec une base de données locale et HyperFile Client/Serveur qui s'exécute en local.

Donc la contre performance est ailleurs.

Code :

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

1
2
WHERE 
	Test.date_Appel BETWEEN {SAI_Date_Debut} AND {SAI_Date_Fin}

La rubrique Test.date_Appel devrait être indexée, c'est à dire qu'il faut déclarer cette rubrique comme clé simple avec doublons.
http://doc.pcsoft.fr/fr-FR/?2011023&...-rubriques-cle

Et puisque tu veux tester WinDev, tu pourrais utilement tester l'assistant d'optimisation d'une requête.
http://doc.pcsoft.fr/fr-FR/?2032021&...on-une-requete
_

[Lo²]

Bonjour à tous,

Une petite précision :
HExecuteRequete(..) ne fait qu'initialiser la requête, à aucun moment le résultat est remonté.

HNbEnr(..) fonctionne en parcourant le résultat de la requête.

Si tu mets une boucle pour lire le contenu de HExecuteRequet(..), tu auras les mêmes temps que le HNbEnr(..).

A mon avis, la recherche de lenteur doit se faire au niveau des indexes.

[ciberju]

Merci pour vos réponses.

La rubrique Test.date_Appel devrait être indexée, c'est à dire qu'il faut déclarer cette rubrique comme clé simple avec doublons.

C'est la première chose que j'ai fait !

Et puisque tu veux tester WinDev, tu pourrais utilement tester l'assistant d'optimisation d'une requête.

Au niveau du HExecuteRequete, comme je l'ai signalé, je n'ai aucun problème de lenteur.
J'ai testé les optimisations et rien n'est conseillé, que ce soit pour la requête Count ou celle du select.

Enfin, je reste etonné que ça prenne autant de temps pour connaître le nombre de champs d'une requête.
Par curiosité, j'ai testé en Access, le résultat des calculs est instantanés.
Lorsque je développe sur SAP, il en est de même.

Je vais essayer via une base SQL serveur pour voir ce qu'il en est. Mais ça me déçoit tout de même par rapport à la réactivité.

[Raptor92]

Bonjour,

Je ne suis pas tout à fait d'accord avec vous lorsque vous dite être déçu par la réactivité.

Dans mon cas, je travaille avec un serveur SQL 2005 et 2008.
Certaines requêtes interrogent la BDD pour lesquelles certaines tables contiennent jusqu'à 300 mille enregistrements, or le temps de réponse ne dépasse pas 1 à 3 minutes pour les plus lourdes.

Maintenant, comme le dit =JBO=, cela doit venir d'ailleurs

Bonne journée

[mogwai162]

...HExecuteRequete(..) ne fait qu'initialiser la requête, à aucun moment le résultat est remonté.

HNbEnr(..) fonctionne en parcourant le résultat de la requête...

tu as tout a fait raison c'est pour cela que je pense qu'une requête COUNT risque d'être plus efficace qu'un HNBEnr.