|
PROFESSIONAL NEWSGROUPS
WINDEV, WEBDEV and WINDEV Mobile |
| | | | | |
| Started by BML, Feb., 14 2006 2:45 PM - 5 replies |
| |
| | | |
|
| |
Posted on February, 14 2006 - 2:45 PM |
lorsque j'éxecute une requete sur un serveur HF, le temps d'execution est sensible au débit de la connexion, même requete s'execute en 80 ms avec 100Mb et 1200 ms avec une connexion de 500 Ko.
Pourtant le resultat de la requete est limité (1 enregsitrement de 115 octets !) mais le fichier contient 1500 enregistrement.
Mais normalement la requete sexecute avec la meme vitesse puiceque Client/serveur. |
| |
| |
| | | |
|
| | |
| |
Posted on February, 15 2006 - 6:36 AM |
Tu fais une erreur sur ce point, ce n'est pas parce que c'est du client
serveur que le debit du réseau ou de l'ADSL n'entre pas en compte. Je te
conseille de lire ces quelques conseils :
http://freedev.windev.free.fr/Page_Client_Serveur_Optimisations.htm
Philippe
http://www.freedev-web.com
"BML" <info@bml-dz.com> a écrit dans le message de news:
43f1cfd7$1@news.pcsoft.fr...
lorsque j'éxecute une requete sur un serveur HF, le temps d'execution est
sensible au débit de la connexion, même requete s'execute en 80 ms avec
100Mb et 1200 ms avec une connexion de 500 Ko.
Pourtant le resultat de la requete est limité (1 enregsitrement de 115
octets !) mais le fichier contient 1500 enregistrement.
Mais normalement la requete sexecute avec la meme vitesse puiceque
Client/serveur.
|
| |
| |
| | | |
|
| | |
| |
Posted on February, 15 2006 - 10:40 AM |
Merci mais, j'ai fait un test avec un projet avec aucune fenetres. seulement la commande HexecuteRequete() sans parcours ni affectation mais le même resultat.
Autre chose, j'ai remarqué des plntages en executant les requetes (aleatoirement) sur plusieurs config. avec la version 9, aucun Pbm. je ne sais si c'est acause du serveur HF ou Client (WD100HF.DLL) ? |
| |
| |
| | | |
|
| | |
| |
Posted on February, 15 2006 - 11:53 AM |
BML a écrit :
lorsque j'éxecute une requete sur un serveur HF, le temps d'execution est sensible au débit de la connexion, même requete s'execute en 80 ms avec 100Mb et 1200 ms avec une connexion de 500 Ko.
Pourtant le resultat de la requete est limité (1 enregsitrement de 115 octets !) mais le fichier contient 1500 enregistrement.
Mais normalement la requete sexecute avec la meme vitesse puiceque Client/serveur.
Dans ce cas, vous ne devez pas être vraiment client/serveur : un petit
test avec ethereal, par exemple, vous permettra d'analyser le trafic que
votre programme génère. |
| |
| |
| | | |
|
| | |
| |
Posted on February, 15 2006 - 12:41 PM |
Sympathique résumé des optimisations client-serveur de base mais je ne suis pas d'accord avec le fait qu'il est systématiquement préférable de baser une table sur une requete et non sur un fichier HF.
Charger une requete utilise beaucoup de mémoire et peut demander un temps d'attente très long si la liaison réseau n'est pas rapide, à plus forte raison encore si il s'agit d'une connexion internet.
En plus, le rafraichissement pose problème car en général, on est bon pour réexécuter toute la requête en ca de modification.
Une liaison fichier en revanche, ne lira que les 15-20 lignes + un petit cache nécessaires a l'affichage dans la table et demandera les autres lignes au fur et à mesure si besoin est. De plus, le rafraichissement se fera très simplement et il sera facilement possible de rafraichir une ligne spécifique.
Je pense en fait que ces deux façons de programmer ont des avantages et inconvénients propres.
Sinon, la limitation des parcours de type Hlit* est bien mise en avant... + 1 |
| |
| |
| | | |
|
| | |
| |
Posted on April, 25 2006 - 3:32 PM |
Pour ma part je viens de faire un test très simple :
Une fenêtre avec 2 boutons :
- le 1° exécute un filtre avec condition sur un fichier, puis lit le fichier et affiche le résultat dans une table mémoire.
- le 2° fait la même chose mais en utilisant une requête.
Le programme est exécuté en client/serveur avec les fichiers sur un serveur à Lyon et le programme dans une de nos agence en France.
Le test montre que la requête est 3 à 4 fois plus rapide que le filtre. |
| |
| |
| | | |
|
| | | | |
| | |
| | |
| |
|
|
|