Optimisation de la vitesse de l'application (multiples requêtes)

**Grmmml** · 11/06/2010, 10h58

Envoyé par 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 ?

Hum, je ne sais pas trop. Tu as plusieurs solutions par code, genre en positionnant un flag global à faux/vrai, ou alors en testant que le thread soit toujours actif (en supposant que tu stop le thread une fois la requete executé)
Il y a surement d'autre méthode, mais je n'ai pas approfondis.

bob.

Envoyé par =JBO=

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.

Effectivement, au temps pour mois, je pensais que le contexte n'étais dupliqué qu'avec l'option "ThreadUtiliseHyperFile"

Bob.

**Aenur56** · 11/06/2010, 11h03

Bon de toute façon, les threads sont apparament une solution à exclure...

Pour l'instant le moyen le plus efficace que j'ai trouvé est d'ouvrir, à l'ouverture de la fenêtre d'accueil, une fenêtre soeur dans laquelle l'utilisateur sélectionne les fonctionnalités du logiciel qu'il souhaite utiliser.
Ainsi, seules les requêtes des fenêtes qu'il utilisera seront exécutées préalablement, ce qui évitera trop de ralentissements inutiles.

**Grmmml** · 11/06/2010, 11h04

Tu peux tout de même utiliser un thread, mais il te faudra alors utiliser des tables mémoires et pré ouvrir les fenêtres en invisible pour remplir les tables via le thread.
Ce qui, je l'admet, revient à fabriquer une usine à gaz

Bob.

**=JBO=** · 11/06/2010, 11h14

Envoyé par 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

Si les temps d'ouverture sont vraiment "critiques", notamment du point de vue de l'utilisateur, et si tu es certain de ne pas obtenir un temps de réponse suffisant via des requêtes exécutées sur la "connexion HF C/S", alors tu peux te retrousser les manches pour mettre en place un système de "fichier temporaire de travail".

Voilà le principe:

Dans l'analyse tu crées un "fichier de travail" qui possède toutes les rubriques retournées par ta requête.
Ce "fichier de travail" sert de modèle pour créer d'autres fichiers, qui recevront chacun les données provenant d'une exécution de ta requête.

Tu crées une procédure stockée (avec des paramètres ?), qui va :

créer un fichier Alias du "fichier de travail",
faire un INSERT INTO NomDuFichierAlias SELECT <code SQL de la requête>
retourner le NomDuFichierAlias.

Ensuite, dans ta fenêtre:

tu exécutes la procédure stockée (avec les paramètres qui vont bien),
tu récupères le nom du fichier Alias et tu déclares le fichier Alias,
tu changes la source de données du champ table pour désigner le fichier Alias.

L'affichage devrait être très rapide puisque la seule chose à faire (sur le poste client) est de récupérer le jeu de données.

Cette méthode est pratique pour afficher des données.
En revanche, elle ne permet pas une mise à jour des données. En effet, le champ table ne travaille que sur une copie des données.
Si tu veux faire des mises à jour de données, alors il faudra les gérer "à la main".
_

**Aenur56** · 11/06/2010, 11h24

Je vais sauvegarder mon projet et faire quelques tests. On verra bien ce que ça donnera

Par contre j'exécute la procédure à l'ouverture de quelle fenêtre ? Celle d'accueil ou la fenêtre contenant la table ?

**=JBO=** · 11/06/2010, 11h30

Envoyé par Grmmml

Tu peux tout de même utiliser un thread, mais il te faudra alors utiliser des tables mémoires et pré ouvrir les fenêtres en invisible pour remplir les tables via le thread.

Pour rester sur l'idée d'un champ table mémoire rempli progressivement, en tâche de fond...
Il est peut-être envisageable d'utiliser la fonction SQLExec() suivi de la fonction SQLTable(), pour un transfert des données dans le champ table mémoire avec "Fetch Partiel".
_

**Aenur56** · 11/06/2010, 11h34

Je vais d'abord tester la solution du fichier de travail ^^ On verra bien ce que ça donnera !

Le fichier de travail d'ailleurs je le met aussi en HF C/S ou en classic ?

**=JBO=** · 11/06/2010, 11h43

Envoyé par Aenur56

Je vais d'abord tester la solution du fichier de travail ^^ On verra bien ce que ça donnera !

Le fichier de travail d'ailleurs je le met aussi en HF C/S ou en classic ?

C'est la procédure stockée qui doit créer un fichier Alias à partir d'un fichier modèle qui est ce "fichier de travail".
Ce fichier Alias sera créé sur le serveur pour recevoir le résultat de l'exécution de la requête... tout ça se passe sur le serveur.
Par conséquent, le "fichier de travail" qui servira de "modèle" doit être sur le serveur.

As-tu vu ma mise en garde dans mon précédent message ?

La technique du "fichier de travail" ne convient pas bien pour effectuer des mises à jour de données.

**Aenur56** · 11/06/2010, 11h49

Je viens de la voir ^^ La table servira uniquement à afficher des données.
Mais si j'insère d'autres données via une autre fenêtre, ces ajouts seront-ils pris en compte lors du prochain affichage de la table ?

**=JBO=** · 11/06/2010, 12h18

Envoyé par Aenur56

Je viens de la voir ^^ La table servira uniquement à afficher des données.
Mais si j'insère d'autres données via une autre fenêtre, ces ajouts seront-ils pris en compte lors du prochain affichage de la table ?

Il faudra d'abord ajouter ces données dans le fichier Alias.
Par exemple, au moyen d'une procédure stockée qui effectue un INSERT INTO limité aux seules nouvelles données.

Code pseudo SQL :

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

1
2
3
INSERT INTO NomDuFichierAlias 
SELECT <code SQL de la requête> 
WHERE <seulement les nouvelles données>

Tu peux aussi réaliser cette insertion directement à partir du poste client, si le temps d'exécution de la requête est correct.

Puis rafraîchir les données du "fichier Alias de travail" affichées dans le champ table.
Par exemple avec ceci:

Code WLangage :

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

TableAffiche(<Nom du champ table>, taCourantEnreg)

_

**=JBO=** · 11/06/2010, 12h40

Encore une réflexion...

Si ton serveur passe trop de temps à créer ces fichiers de travail, tu peux envisager une approche plus "radicale".

A savoir, au lieu d'un fichier de travail (temporaire), tu ajoutes dans ton analyse un "fichier de synthèse" (c'est un fichier permanent qui fait vraiment partie de ton analyse).
Les données de ce fichier de synthèse seront "automatiquement" créées/modifiées/supprimées à chaque création/modification/suppression dans le fichier de référence qui contient les "données vivantes".

Pour ça, il faut utiliser des Triggers serveur (déclencheurs).

Avantages de cette méthode:

les données sont toujours prêtes pour être affichées dans le champ table,
le fichier de synthèse peut être "optimisé" avec des index et complété par des rubriques "utiles",
il n'y a rien à programmer dans l'application,
pas de gestion de fichier Alias,
le serveur est moins sollicité puisque les données du fichier de synthèse sont renseignées au fil du temps.

_

**Aenur56** · 11/06/2010, 12h48

Je sens que rien qu'avec les solution que tu proposes, je vais pouvoir essayer toutes les fonctionnalités possible et imaginables proposées par WinDev

En effet, l'utilisation des Triggers m'a l'air d'être interessante, il faut juste que je comprenne comment les utiliser et que je teste ça...

En une semaine de stage qu'il me reste, ça va être chaud les marrons

En tout cas un grand merci pour tes réponses toujours bien détaillées et utiles.

**=JBO=** · 11/06/2010, 13h34

Envoyé par Aenur56

En effet, l'utilisation des Triggers m'a l'air d'être interessante, il faut juste que je comprenne comment les utiliser et que je teste ça...

Il faut que tu regardes du côté des Triggers serveur, et dans ton cas ce sera des Triggers "APRÈS" :
http://doc.pcsoft.fr/fr-FR/?3044369&...iggers-serveur

Attention, à ne pas faire de confusion avec les Triggers "applicatif".

Tu ne dois pas utiliser de Trigger applicatif.

Un Trigger "applicatif" est exécuté par l'application, sur le poste Client, à la demande du moteur HyperFile utilisé "localement" par l'application.
http://doc.pcsoft.fr/fr-FR/?3044271&...iggers-simples
_

**CaDegenere** · 13/06/2010, 01h38

Envoyé par Aenur56

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 ?

Bonsoir,

Juste au cas où, as tu essayé de compresser les données ? (http://doc.pcsoft.fr/fr-FR/?1000017276)

**Aenur56** · 14/06/2010, 09h10

Non je n'ai pas essayé mais d'après ce que j'en lit, ça peut pallier en parti à mon problème... merci pour l'idée CaDegenere

Dès que je peux essayer ça je vous tiens au courant

**mogwai162** · 14/06/2010, 11h11

Attention avec la compression, c'est à réserver à des réseaux lents. sinon la compression/décompression va prendre plus de temps que le gain de transfert de données.

**Aenur56** · 14/06/2010, 12h02

Et bien justement, étant donné que l'exécution de la requête met maximum 7 - 8 secondes sur mon poste et plus de 20 minutes sur le poste de l'utilisateur, je pense que c'est plus dû à une lenteur du réseau qu'à un problème de puissance de l'ordinateur vous ne pensez pas ?

La solution est à essayer, je devrais pouvoir tester ça demain.

**Aenur56** · 16/06/2010, 16h09

Le problème est résolu !

C'était en effet un problème de lenteur de réseau et la compression des données a résolu mon problème.
Sur le poste sous XP, les requêtes qui auparavant mettaient plusieurs minutes à s'exécuter se font en quelques secondes seulement.

Merci à tous pour votre aide et vos conseils, ils m'ont été bien utiles !

**=JBO=** · 17/06/2010, 13h44

Bonjour,

Envoyé par Aenur56

C'était en effet un problème de lenteur de réseau et la compression des données a résolu mon problème.
Sur le poste sous XP, les requêtes qui auparavant mettaient plusieurs minutes à s'exécuter se font en quelques secondes seulement.

J'ai du mal à croire que la seule compression des données permette de faire passer le temps d'attente de quelques minutes à quelques secondes.

A mon avis, cette amélioration provient aussi d'autres corrections.
_

**Aenur56** · 17/06/2010, 13h57

Il est vrai que c'est étrange, d'autant plus que le responsable du service informatique m'a dit que le réseau était le même sur tout l'établissement...

Je suis à peu près sûr de n'avoir rien modifié de plus dans l'analyse ou le code.

Ba l'important c'est que ça marche

Vu qu'il me reste 2 jours de stage il était temps

Optimisation de la vitesse de l'application (multiples requêtes) [WD14]

WinDev

Discussions similaires

Partager

Partager