|
PROFESSIONAL NEWSGROUPS
WINDEV, WEBDEV and WINDEV Mobile |
| | | | | |
| Started by Arnaud, Mar., 16 2006 7:30 PM - 8 replies |
| |
| | | |
|
| |
Posted on March, 16 2006 - 7:30 PM |
Nous avons programmé une application en n'utilisant que des requêtes dont une est affectée à une table (Requête simple optimisée et créée sous l'éditeur de requête). SELECT * FROM SOCIETES
Lors de nos tests, il apparait que pour 70000 enregistrements :
Le temps est de 14 secondes lors de l'affichage en client Serveur
Le temps est quasi immédiat en Hyperfile clasique ou nous avons attaché le fichier SOCIETES à la table et non une requête
Cela nous semble incohérent
Nous avons constaté que nos pertes de temps se passaient lors de l'affichage de la table
Auriez-vous des idées pour optimiser ces temps d'accès
Merci |
| |
| |
| | | |
|
| | |
| |
Posted on March, 16 2006 - 9:14 PM |
Bonsoir,
Il y a plusieurs points:
1. select * from societe est tout sauf une requête optimisée, puisque le serveur renvoie la totalité de la table.
2. Dans le cas de HF classique, si la table est liée au fichier, Windev utilise le fetch partiel : seuls les enregistrements affichés ont transité sur le réseau. Dans votre cas, puisque la table est basée sur une requête, tous les enregistrements transitent, d'où le délai d'affichage.
Frédéric. |
| |
| |
| | | |
|
| | |
| |
Posted on March, 16 2006 - 9:14 PM |
"Arnaud" <abailleul@winjob.net> writes:
Nous avons programmé une application en n'utilisant que des requêtes
dont une est affectée à une table (Requête simple optimisée et créée
sous l'éditeur de requête). SELECT * FROM SOCIETES Lors de nos tests,
il apparait que pour 70000 enregistrements : Le temps est de 14
secondes lors de l'affichage en client Serveur
C'est bien pour 70 000 enregistrements. Quel est l'intéret de remonter
autant d'enregistrement dans une requête?
Le temps est quasi
immédiat en Hyperfile clasique ou nous avons attaché le fichier
SOCIETES à la table
C'est normal il affiche uniquement les données visible à l'écran
> et non une requête Cela nous semble incohérent
cela ne l'est pas ce sont les mécanismes qui sont différents
Nous avons constaté que nos pertes de temps se passaient lors de
l'affichage de la table Auriez-vous des idées pour optimiser ces temps
d'accès Merci
1 /Voir si il est nécessaire de remonter autant de ligne
2/ faire un limit qui correspond au nombre visible de ligne en faisant
ensuite un scroll avec l'ascenseur qui va rappeler des données..
--
suivre ce lien pour répondre:
http://cerbermail.com/…
Daniel
 |
| |
| |
| | | |
|
| | |
| |
Posted on March, 16 2006 - 9:15 PM |
C'est 70000 enregistrements remontés ? Quel est le but de remonter tous les résultats chez le client ? Une table avec 70000 enregistrements personne ne la parcourt !!! |
| |
| |
| | | |
|
| | |
| |
Posted on March, 17 2006 - 10:25 AM |
J'ai eu le même probleme en C/S avec seulement 32000 enregistrements:
comme la remontée des 32 000 enregs etait lente, j ai ecris une requete qui ne prend que les 24 premiers enregs a partir d'une certaine position:
Select top 24 * from Tab_Ville where VI_CodePostal >= {ParamCP} order by VI_CodePostal
et a la place de ParamCP je met le i-ème code postal que je me suis debrouiller pour recuperer avec un HLitRecherchePremier.
Eh bien le rapatriment de la requête est ultra-rapide parcqu'il n y a que 24 enregs... le probleme c est que sur 32000 enregs seulement le "top 25" allié au "order by" fait que la requête met 9,8 secondes a s executer, et ce sur un Athlon 2600+, 256 ram (on a suivi l utilisation du proce qui grimpe a 100% pendant les 10 secondes de la requete...)
C'est normal un temps pareil???
(juste pour voir on a fait la meme requete sur une table identique en SQL serveur et le temps a été de 0,01 seconde environs)
et oui VI_CodePostal est une clé de parcours.
Des idées? |
| |
| |
| | | |
|
| | |
| |
Posted on March, 17 2006 - 11:33 AM |
Phil avait soumis l'idée :
C'est 70000 enregistrements remontés ? Quel est le but de remonter tous les
résultats chez le client ? Une table avec 70000 enregistrements personne ne
la parcourt !!!
Utilisant toujours HF Classic, je sais pourquoi 70000 enregistrement
dans la table, c'est interressant.
Le loupe permet de rechercher instantanément un enregistrement sur ces
70000. (sur un fichier, un code et un libellé en clé et la recherche
est toute faite.)
Moi aussi, je pense passer à HF/CS, mais utilisant beaucoup les table
fichier, sans filtre pour tous les dictionnaires, proposer une solution
interressante m'interresse également.
A priori, la solution est de gérer les evennements qui changent
l'affichage de la table (fleche Haut bas, ascenseur hau bat ... comme
au temps du doss
Mais Quid de la recherche automatique ... Niet? la gérer également a la
main.
Et voilà le passage de HF classic => Client serveur en 3 lignes de
codes à l'ouverture du projet s'envole ...
(moi, j'ai des dictionnaire de 300 000 enreg géré en table fichier avec
recherche loupe (recherche opérationnelle, fonctionnelle et
instantannée...) Bien sur avec possibilité de tris, mais le filtre
renvoi régulièrement plus de 50 000 enreg.
Cordialement |
| |
| |
| | | |
|
| | |
| |
Posted on March, 17 2006 - 11:58 AM |
Bonjour,
Il n'y a rien à programmer en client/serveur pour garder la recherche par la
loupe en client/serveur, c'est même beaucoup plus rapide dans les cas que
j'ai pu observer.
Par exemple avec un fichier contenant des emails, un peu moins de 400 000
enregistrements, la loupe donne un résultat immédiat dans une table fichier
sans aucun filtre.
Par contre attention, la table de sélection qui prend tout le fichier ne
contient pas toutes les rubriques du fichier. Les champs contenant le gros
du volume (mémo) sont lus à la demande par la suite.
Elian Lacroix.
"Vbig" <PtitScar@hotmail.fr> a écrit dans le message de news:
mn.8a4d7d63749bbad4.46199@hotmail.fr...
Phil avait soumis l'idée : C'est 70000 enregistrements remontés ? Quel est le but de remonter tous
les
résultats chez le client ? Une table avec 70000 enregistrements personne
ne
la parcourt !!!
Utilisant toujours HF Classic, je sais pourquoi 70000 enregistrement dans la table, c'est interressant. Le loupe permet de rechercher instantanément un enregistrement sur ces 70000. (sur un fichier, un code et un libellé en clé et la recherche est toute faite.) Moi aussi, je pense passer à HF/CS, mais utilisant beaucoup les table fichier, sans filtre pour tous les dictionnaires, proposer une solution interressante m'interresse également. A priori, la solution est de gérer les evennements qui changent l'affichage de la table (fleche Haut bas, ascenseur hau bat ... comme au temps du doss Mais Quid de la recherche automatique ... Niet? la gérer également a la main. Et voilà le passage de HF classic => Client serveur en 3 lignes de codes à l'ouverture du projet s'envole ... (moi, j'ai des dictionnaire de 300 000 enreg géré en table fichier avec recherche loupe (recherche opérationnelle, fonctionnelle et instantannée...) Bien sur avec possibilité de tris, mais le filtre renvoi régulièrement plus de 50 000 enreg. Cordialement |
| |
| |
| | | |
|
| | |
| |
Posted on March, 17 2006 - 12:42 PM |
Elian a émis l'idée suivante :
Bonjour,
Il n'y a rien à programmer en client/serveur pour garder la recherche par la
loupe en client/serveur, c'est même beaucoup plus rapide dans les cas que
j'ai pu observer.
Par exemple avec un fichier contenant des emails, un peu moins de 400 000
enregistrements, la loupe donne un résultat immédiat dans une table fichier
sans aucun filtre.
Par contre attention, la table de sélection qui prend tout le fichier ne
contient pas toutes les rubriques du fichier. Les champs contenant le gros
du volume (mémo) sont lus à la demande par la suite.
Donc en gros, pour Anraud, il ne faut pas qu'il fasse une requete
select * from societe mais qu'il branche sa table sur le fichier
societe comme en hf classic et il n'a plus de problème ? |
| |
| |
| | | |
|
| | |
| |
Posted on March, 17 2006 - 1:04 PM |
"Vbig" <PtitScar@hotmail.fr> writes:
Phil avait soumis l'idée : C'est 70000 enregistrements remontés ? Quel est le but de remonter
tous les résultats chez le client ? Une table avec 70000
enregistrements personne ne la parcourt !!!
Utilisant toujours HF Classic, je sais pourquoi 70000 enregistrement dans la table, c'est interressant. Le loupe permet de rechercher instantanément un enregistrement sur ces 70000. (sur un fichier, un code et un libellé en clé et la recherche est toute faite.)
Rien n'empêche de faire la même chose si vous remontée uniquement
quelques lignes, maintenant c'est vrai qu'il va falloir coder un peu.
Moi aussi, je pense passer à HF/CS, mais utilisant beaucoup les table fichier, sans filtre pour tous les dictionnaires, proposer une solution interressante m'interresse également. A priori, la solution est de gérer les evennements qui changent l'affichage de la table (fleche Haut bas, ascenseur hau bat ... comme au temps du doss Mais Quid de la recherche automatique ... Niet? la gérer également a la main.
Oui
Et voilà le passage de HF classic => Client serveur en 3 lignes de
codes à l'ouverture du projet s'envole ...
L'intéret d'un client/serveur n'est pas de remonter toutes les lignes,
ce que ne fait pas de toute façon HF classique, le meilleur moyen de
le voir est de mettre la base sur une autre machine et de regarder le
traffic généré sur le réseau.
(moi, j'ai des dictionnaire de 300 000 enreg géré en table fichier
avec recherche loupe (recherche opérationnelle, fonctionnelle et
instantannée...) Bien sur avec possibilité de tris, mais le filtre
renvoi régulièrement plus de 50 000 enreg.
Cordialement
--
suivre ce lien pour répondre:
http://cerbermail.com/…
Daniel
|
| |
| |
| | | |
|
| | | | |
| | |
| | |
| |
|
|
|