Discussion :

[Aenur56]

Bonjour,

Dans le cadre de mon stage, je réalise un gestionnaire de cartes à puces.
J'ai de nombreux tableaux liés à des requêtes qui m'affichent les données nécessaires pour chaque fonctionnalités de l'application. Mon analyse est en HyperFileSQL C/S.

Sur mon poste tournant sous Vista, assez puissant, mes requêtes mettaient pas mal de temps à s'exécuter (entre 3 et 5 sec.), principalement une qui affiche un historique de toutes les opérations effectuées sur les cartes (7 ou 8 sec.).
J'ai installé l'application sur un poste moins puissant, tournant sous XP, et là l'ouverture des fenêtres contenant des tables fichiers liées à des requêtes sont extrêmement longues. Le temps ne se compte plus en secondes mais en minutes, voir plus pour mon historique (après 30 min d'attente, on a finalement arrêté le programme).

Pour remédier à ces lenteurs, j'ai exécuté mes requêtes (avec HOptimiseRequête puis HExecuteRequête) à l'initialisation de ma page d'accueil.
Sur mon poste, la différence de temps était notable. En effet, l'exécution de l'initialisation de la fenêtre, qui exécutait pourtant toutes les requêtes un peu longues, ne prenait que 2 ou 3 sec maximum et l'ouverture des fenêtres contenant les tables s'effectuait instantanément.
Je m'étais donc dit que si je laissais l'application ainsi, il ne faudrait que quelques minutes d'attente à l'ouverture sur un poste moins puissant et qu'ensuite, les fenêtres s'ouvriraient rapidement.

Le problème, c'est que ce n'est pas le cas.
J'ai installé ce matin l'application sur le même poste sous XP que précédemment, et là la page d'accueil se bloque. J'ai attendu une bonne vingtaine de minutes avant de rendre les armes.

Maintenant, j'essaye d'optimiser au maximum les requêtes à exécuter en permettant par exemple à l'utilisateur de choisir à l'ouverture de la fenêtre d'accueil les fonctionnalités du logiciel qu'il désire utiliser. A la validation, seules les requêtes correspondantes aux éléments choisis seront exécutées.

Y-aurait-il un moyen un peu moins barbare et plus simple d'accélérer l'exécution de mes requêtes (qui sont toutes optimisées au maximum) ?
Malgré mes recherches, je n'ai rien trouvé de concluant .

Merci d'avance,

Aenur.

[Lo²]

Salut à toi,

...Sur mon poste tournant sous Vista, assez puissant, mes requêtes mettaient pas mal de temps à s'exécuter (entre 3 et 5 sec.), principalement une qui affiche un historique de toutes les opérations effectuées sur les cartes (7 ou 8 sec.)... (qui sont toutes optimisées au maximum)

Une petite remarque : des requêtes qui mettent 3-5s sur un poste que tu considères puissant, je ne vois pas où se trouve l'optimisation des requêtes, si la lenteur provient effectivement de celles-ci.

Ensuite, il faut noter que tous les champs d'une fenêtre sont initialisés avant l'affichage de la fenêtre, cad que si tu utilises 30 plans avec chacun 10 tables fichiers, tu auras 300 tables qui seront initialisées avant de voir le premier pixel de la fenêtre.

Ensuite, niveau requêtage, il faut te pencher sur les indexes existants et regarder si tes requêtes les utilisent ou s'il faut créer d'autres indexes.

Aussi :
- as-tu utilisé le profiler pour pointer l'origine de ces lenteurs ?
- utilises-tu un serveur HF ?
- utilises-tu des procédures stockées ?

[Aenur56]

J'ai indexé le maximum de rubriques que mes requêtes utilisent. D'après l'outil d'optimisation des requêtes, je ne peux pas les optimiser plus qu'elles ne le sont déjà.

J'ai en effet profilé le projet (sous vista) et c'est d'ailleurs de ça que je tire les temps d'exécution que j'ai cités. Ils proviennent à chaque fois de l'ouverture d'une fenêtre contenant une table fichier liée à une requête.
D'ailleurs, depuis la page d'accueil, chaque fenêtre que l'on ouvre comporte une seule table fichier donc le temps était long à l'ouverture de chaque fenêtre.
C'est d'ailleurs pour cela que j'ai voulu exécuter les requêtes au lancement de l'application : l'exécution était plus rapide et une fois la page d'accueil chargée, les fenêtres que j'ouvrait par la suite étaient affichées instantanément puisque les requêtes étaient préalablement exécutées.

Sinon, j'utilise un serveur HF et je n'ai aucune procédure stockée.

J'ai aussi pensé à quelque chose... L'ordinateur (vista) sur lequel je travaille au service informatique a un meilleur accès au réseau que celui (xp) sur lequel j'ai installé l'application. Cela peut-il jouer dans la vitesse de l'application ?

[Lo²]

L'accès réseau est bien sûr un paramètre à prendre en compte, mais à mesurer, je n'ai pas les connaissances pour savoir comment.

Je t'ai parlé des procédures stockées en pensant à un accès réseau réduit, qui est mon cas de figure.
Je bosse à distance sur un VPN pas glop et d'un requêtage simple qui me prenait 10s, je suis passé à 1-2s avec une procédure stockée.

Il y a des pour et des contre leur utilisation, surtout au niveau maintenance.

Sur une serveur HF, par contre, je n'ai malheureusement pas d'expérience, mais à mon avis, c'est une voie à explorer.
Edit : Je bosse sur DB2/400, MSSQL et Postgre d'où mon inexpérience en HF ^^

[mogwai162]

Si tu es en CS, tu dois avoir sur le serveur de quoi analyser tes requêtes et ainsi lister celles qui te prennent le plus de temps.

Une fois ceci fait, tu dois pouvoir utiliser des procédures ou des requêtes stockées.

Veille tout de même à ce que tes requêtes te renvoient strictement ce dont tu as besoin et pas plus et en terme de champs et en terme d'enregistrements.

[tatayo]

Bonjour,
Tu peux aussi utiliser AnalyseurDebut() et AnalyseurFin() pour créer un fichier "de trace", que tu peux ensuite ouvrir dans l'analyseur de performance.
Tu sauras ainsi ce qui prend du temps.

Tatayo.

[Aenur56]

Merci beaucoup pour vos réponses, ça me donne des pistes

Je sais bien ce qui me prend du temps : comme je l'ai dit avant, j'ai 4 requêtes qui traînent la patte un peu, dont une plus que les autres.

Sinon, comment fonctionnent les procédures et requêtes stockées ?

J'ai cherché mais je n'ai rien trouvé d'assez compréhensible pour moi

[Aenur56]

Bon finalement en cherchant bien j'ai réussi à trouver des infos assez claires et j'ai donc sotcké la requête qui prenait le plus de temps.
Cependant, je n'ai pas l'impression de gagner en vitesse d'exécution, en tout cas sous vista. Peut être que cela se verra sur un poste moins puissant.

Il n'y a rien d'autre à faire après avoir stocké la requête ?

[mogwai162]

Ben non pas trop.

Utilise tu bien la requête stockée ? as tu bien les index adéquats ? Le temps est il identique ou un peu meilleur ?

[Aenur56]

Et bien, j'ai seulement importée ma requêtes dans les requêtes sotckées.
J'ai vérifié que je la retrouvais bien dans le centre de contrôle HFSQL et à part ça je n'ai rien modifié à mon code, il contient toujours des HExecuteRequete(LaRequeteStockée) pour l'exécuter.

Qu'entends-tu par les index adéquats ?

Sinon pour le temps d'exécution et bien je ne crois pas qu'il ai changé, après il faudrait voir sur le poste moins puissant ça changerait peut être quelque chose... (mais je ne pourrais intervenir sur ce poste qu'en début de semaine prochaine).

[=JBO=]

Bonjour,

Je ne suis pas assez expérimenté pour te guider précisément.
Mais j'ai des doutes sur le principe même d'une requête stockée directement utilisée par l'application pour récupérer un jeu de données.

Bon finalement en cherchant bien j'ai réussi à trouver des infos assez claires et j'ai donc sotcké la requête qui prenait le plus de temps.
Cependant, je n'ai pas l'impression de gagner en vitesse d'exécution, en tout cas sous vista. Peut être que cela se verra sur un poste moins puissant.

Il n'y a rien d'autre à faire après avoir stocké la requête ?

A mon avis, une requête stockée ne peut être exécutée que par une procédure stockée...

Maintenant, tout n'est pas perdu.

As-tu essayé d'utiliser la fonction HExécuteRequête() en spécifiant une connexion vers le serveur HF ?
Lis bien l'aide en ligne pour voir comment faire.

A essayer de toute urgence.
_

[Aenur56]

Je viens de comparer HExecuteRequete(Requete) et HExecuteRequete(Requete,Connexion) mais le résultat ne change pas beaucoup, l'exécution de la requête est toujours compris entre 30 et 50 ms...

C'est bizarre quand même parce que si j'ouvre la fenêtre contenant la table liée à la requête sans exécuter préalablement celle-ci, la fenêtre met un peu plus de 6 s. à s'ouvrir et si j'exécute la requête avant (entre 30 et 50 ms), la fenêtre s'ouvre instantanément...

Est-ce normal que le temps d'exécution de la requête avec un HExecuteRequete() soit tellement plus rapide que l'exécution de la requête à l'initialisation de la table qui lui est liée ?

[Grmmml]

Salut,

Je tiens juste à préciser qu'en toute logique, les procédure stockées apportent des gains de performances significatif uniquement pour la mise en œuvre de traitement complexe (i.e. qui ne se résumes pas à une seule requête) de mise à jour de la base de données

Si ta procédure stockées se contente de faire un "SELECT" alors le gain sera minime, voire même nul. Dans tous les cas "le temps" passé dans la requête sera le même : temps de sélection de toute les lignes + temps de retour des lignes.

Dans les explications que tu donnes sur ton programme, tu indiques que tu as transféré l'exécution des requêtes du code d'ouverture des fenêtre dans l'ouverture du projet (ou qcq chose du genre). Ce faisant, tu as simplement déplacé le temps d'attente de chaque fenêtre dans l'initialisation du programme. Tu ne pouvais pas gagner du temps.

Une piste serait de lancer l'exécution des requêtes en arrière plan au lancement du programme en utilisant un thread séparé.
Reste en suite, à l'ouverture de chque fenêtre à t"assuré que la requête à bien été exécutée.
Cette technique te permet juste de gagner en "fluidité" lors de l'utilisation du programme. Pour accélérer les requêtes il faut travailler sur la structure de la base de donnée et sur le code des requêtes

Bob.

[=JBO=]

Je viens de comparer HExecuteRequete(Requete) et HExecuteRequete(Requete,Connexion) mais le résultat ne change pas beaucoup, l'exécution de la requête est toujours compris entre 30 et 50 ms...

Ce n'est peut-être pas perceptible sur ton poste de développement, mais ça reste à voir sur le poste XP où la requête mettait plus de 20 minutes à s'exécuter.
As-tu essayé ?

Est-ce normal que le temps d'exécution de la requête avec un HExecuteRequete() soit tellement plus rapide que l'exécution de la requête à l'initialisation de la table qui lui est liée ?

Si tu fais un HExecuteRequete() avant d'ouvrir la fenêtre, alors la requête est déjà exécutée, et le champ table n'a plus qu'à afficher les données.
_

[Lo²]

...Si ta procédure stockées se contente de faire un "SELECT" alors le gain sera minime, voire même nul. Dans tous les cas "le temps" passé dans la requête sera le même : temps de sélection de toute les lignes + temps de retour des lignes...

Je ne suis pas aussi catégorique sur ce point dans le sens où j'ai eu des temps 4-5 fois plus rapides sur des SELECT (environnement : VPN + DB2/400).

[Lo²]

Je viens de comparer HExecuteRequete(Requete) et HExecuteRequete(Requete,Connexion) mais le résultat ne change pas beaucoup, l'exécution de la requête est toujours compris entre 30 et 50 ms...

Ton premier post mentionne des temps de 3-5 sec et non 30-50 ms...

[Aenur56]

@Bob : Il y a un moyen de savoir si la requête a bien été exécutée à l'ouverture d'une fenêtre ? Et si elle n'a pas été complètement exécutée, reprend-elle l'exécution à zéro à l'ouverture de la fenêtre ou attend-elle que sont exécution soit terminée pour afficher la fenêtre ?

Je vais essayer avec les threads au lancement du programme. Le temps que l'utilisateur s'authentifie, je pense que les requêtes ne prenant pas trop de temps (mais quand même quelques secondes sur le poste sous XP) auront le temps de s'exécuter. Je vous tiens au courant

@JBO : Pour le poste sous XP, je ne pourrais voir ça qu'en début de semaine prochaine Je pense que je vais mettre en place toutes les solutions que vous m'avez proposées (avec un système de choix) et les tester une à une pour voir laquelle est la plus rapide.

@Lo² : Dans le premier post, je mentionne l'ouverture des fenêtres contenant les tables qui prennent ce temps là. Après, je parle du temps d'exécution des requêtes avec HExecuteRequete() (temps que j'ai observé en profilant le projet)

[Grmmml]

Je ne suis pas aussi catégorique sur ce point dans le sens où j'ai eu des temps 4-5 fois plus rapides sur des SELECT (environnement : VPN + DB2/400).

Si on ne parle pas de base de donnée HFCS je suis d'accord. Un vrai SGBDR va préparer un plan d'exécution de la requête contenue dans la proc stockée et va le conserver en mémoire.
Mais cette opération de préparation peut aussi être effectuée à la demande, ça n'est pas un méchanisme propre au proc stockée

En windev c'est l'ordre HPrepareRequete qui ne peut pas être utilisé sur des bases HF

Sur les bases de données HyperFileSQL (HyperFileSQL Classic ou Client/Serveur) ou sur les bases xBase, cette fonction ne peut pas être utilisée.

bob.

[=JBO=]

@Bob : Il y a un moyen de savoir si la requête a bien été exécutée à l'ouverture d'une fenêtre ? Et si elle n'a pas été complètement exécutée, reprend-elle l'exécution à zéro à l'ouverture de la fenêtre ou attend-elle que sont exécution soit terminée pour afficher la fenêtre ?

Je vais essayer avec les threads au lancement du programme. Le temps que l'utilisateur s'authentifie, je pense que les requêtes ne prenant pas trop de temps (mais quand même quelques secondes sur le poste sous XP) auront le temps de s'exécuter. Je vous tiens au courant

Je crois que dans ton cas de figure, l'utilisation d'un thread est une fausse piste.

En effet, un thread est exécuté avec un contexte HyperFile indépendant.
Par conséquent, tu ne pourras pas récupérer dans le contexte HyperFile de ta fenêtre, le jeu de données qui provient de l'exécution de la requête dans un thread...
Ce jeu de données se trouve dans un autre contexte HyperFile, distinct de celui de la fenêtre.
Ok ?

Thread et HyperFileSQL

Lors de l'exécution de la fonction ThreadExécute, les contextes HyperFileSQL sont automatiquement dupliqués : il y a autant de contextes HyperFileSQL que de threads en cours d'exécution. La totalité du contexte HyperFileSQL est recopiée (filtre, condition de recherche, ...). Dans chaque thread, le contexte HyperFileSQL évolue indépendamment.

[Aenur56]

En effet, je viens de tester l'utilisation d'un thread qui exécute les requêtes mais l'ouverture de mes fenêtres reste toujours aussi longue