|
FORUMS PROFESSIONNELS
WINDEV, WEBDEV et WINDEV Mobile |
| | | | | |
| Débuté par bedarieux.bureau.seb, 06 jan. 2006 19:11 - 16 réponses |
| |
| | | |
|
| |
Posté le 06 janvier 2006 - 19:11 |
j'utilise un appli en C/S par adsl
|ma vitesse d'émission est de 550kb
le utilisateurs distants ne sont pas satisfaits de la vitesse de l'appli
connaissez-vous un moyen d'accellerer manta ? je dispose d'un serveur sous
windows et d'un autre sous linux en mandriva 2006. j'ai essayé les 2, la
vitesse est la même...
manta exploite t'il tout la bande passante ? y'a t'il un réglage à faire au
niveau du routeur ? quelles solutions avez vous essayé ? |
| |
| |
| | | |
|
| | |
| |
Posté le 09 janvier 2006 - 09:39 |
Salut !
On 6-Jan-2006, "sebastien cabanes" <bedarieux.bureau.seb@wanadoo.fr> wrote:
j'utilise un appli en C/S par adsl ma vitesse d'émission est de 550kb
le utilisateurs distants ne sont pas satisfaits de la vitesse de l'appli
connaissez-vous un moyen d'accellerer manta ? je dispose d'un serveur
sous windows et d'un autre sous linux en mandriva 2006. j'ai essayé les 2, la
vitesse est la même...
manta exploite t'il tout la bande passante ? y'a t'il un réglage à faire
au niveau du routeur ? quelles solutions avez vous essayé ?
Je suis assez surpris car en ce qui me concerne, chez un client (9 magasins
connectés par ADSL + 4 utilisateurs distants par ADSL + 5 postes en réseau
local), malgré le fait que certains fichiers de la base de données
contiennent près de 4000.000 enregistrements, mes clients distants ne se
plaignent pas des temps de réponses.
As-tu bien optimisé ton applications pour le C/S (Utilisation de requètes
ne ramenant que les infos nécessaires, bannir les combos et les tables
fichiers, etc.) ?
As-tu vérifié aussi si tu as bien optimisé tes index pour les requètes
utilisées ?
Bien à toi !
--
Marcel Berman
c/o Managing Business SPRL
Allée du Petit Paris, 11
B - 1410 - Waterloo
Tel : +32 2 351.60.64
Fax : +32 2 351.45.78
Gsm : +32 475.799.477 |
| |
| |
| | | |
|
| | |
| |
Posté le 09 janvier 2006 - 09:42 |
Ce n'est pas Manta qu'il faut accélerer, c'est la vitesse upload de votre
ligne ADSL.
--
Cordialement.
Patrick Bouquet
Membre WINDASSO - Association des utilisateurs WxxDEV(c)
http://www.windasso.org
"sebastien cabanes" <bedarieux.bureau.seb@wanadoo.fr> a écrit dans le
message de news: 43bea388$1@news.pcsoft.fr...
j'utilise un appli en C/S par adsl ma vitesse d'émission est de 550kb
le utilisateurs distants ne sont pas satisfaits de la vitesse de l'appli
connaissez-vous un moyen d'accellerer manta ? je dispose d'un serveur
sous windows et d'un autre sous linux en mandriva 2006. j'ai essayé les 2, la
vitesse est la même...
manta exploite t'il tout la bande passante ? y'a t'il un réglage à faire
au niveau du routeur ? quelles solutions avez vous essayé ?
|
| |
| |
| | | |
|
| | |
| |
Posté le 09 janvier 2006 - 09:44 |
vous devez avoir les memes pb que j'ai,
toutes les requetes que vous avez developpe pour hyperfile classique en reseau normal doivent etre revues de la meme maniere que sql.
Les fenetres de presentation egalement si vous avez des rech sur rubriques par caractere.
Les ouvertures de ficheirs aussi, etc etc.... |
| |
| |
| | | |
|
| | |
| |
Posté le 09 janvier 2006 - 09:53 |
sebastien cabanes a présenté l'énoncé suivant :
j'utilise un appli en C/S par adsl ma vitesse d'émission est de 550kb
le utilisateurs distants ne sont pas satisfaits de la vitesse de l'appli
connaissez-vous un moyen d'accellerer manta ? je dispose d'un serveur sous
windows et d'un autre sous linux en mandriva 2006. j'ai essayé les 2, la
vitesse est la même...
manta exploite t'il tout la bande passante ? y'a t'il un réglage à faire au
niveau du routeur ? quelles solutions avez vous essayé ?
Salut,
550 kb (kbit ou kbyte soit ko)=4 Mégabit/sec je suppose ? sinon c'est
lent...550 kbit..
Quelle structure ?
Quel type de données ?
Privilégier les requêtes, les vues...
Eviter les Hfiltre sur les fichiers...
Dminuer au maximum les transferts d'info....
Tu serais étonné de l'amélioration des choses
A+
--
Dr J-M des Grottes
Gestionnaire du Registre des Néphrologues Francophones de Belgique |
| |
| |
| | | |
|
| | |
| |
Posté le 09 janvier 2006 - 10:24 |
tout d'abord merci pour vos réponses
je vous confirme donc que ma vitesse d'emission est bien de 550Kbits (je
sais patrick que c cette vitesse qu'il me faudrait accelerer mais c le
meilleur abo dispo dans ma ville (debimax wanadoo))
j'ai utilisé au maxi les requettes et autres trucs conseillés en c/s. mais
la question ke je me pose est : Est ce ke le moteur manta utilise bien tte
la bande passante dispo ? tout est-il optimisé au niveau du routeur etc ...
merci pour vos infos...
"sebastien cabanes" <bedarieux.bureau.seb@wanadoo.fr> a écrit dans le
message de news: 43bea388$1@news.pcsoft.fr...
j'utilise un appli en C/S par adsl ma vitesse d'émission est de 550kb
le utilisateurs distants ne sont pas satisfaits de la vitesse de l'appli
connaissez-vous un moyen d'accellerer manta ? je dispose d'un serveur
sous windows et d'un autre sous linux en mandriva 2006. j'ai essayé les 2, la
vitesse est la même...
manta exploite t'il tout la bande passante ? y'a t'il un réglage à faire
au niveau du routeur ? quelles solutions avez vous essayé ?
|
| |
| |
| | | |
|
| | |
| |
Posté le 09 janvier 2006 - 12:11 |
On dit d'utiliser les requetes pour accélérer les applications C/S, c'est vrai pour les traitements mais faux pour l'affichage des tables.
Si vous basez une table sur une requete ou une vue, WD va mettre en mémoire tout le résultat de la requête (pas de fetch partiel), et transporter 10000 lignes d'un fichier en local à travers internet, c'est long.
Utilisez de préférences des liaisons avec les fichiers de données, ainsi, seules les données affichées plus un petit cache seront téléchargées.
En revanche, pour les traitements (parcours hlit, filtres), donnez une nette préférence aux requêtes et aux vues. |
| |
| |
| | | |
|
| | |
| |
Posté le 09 janvier 2006 - 12:46 |
je ne comprends pas trop cette histoire de fetch. Prenons un exemple concret
si tu veux bien. j'ai une recherche à faire sur un fichier de 40.000
enregistrements, je dois afficher les résultats dans une table. j'utilise
actuellement une requete avec la table liée a celle-ci. pour ce cas précis,
quelles modifications me conseille tu de faire ? (j'ai déjà optimisé ma
requete avec les trucs automatiques)
merci pour ta réponse
"sebastien cabanes" <bedarieux.bureau.seb@wanadoo.fr> a écrit dans le
message de news: 43c21d08$1@news.pcsoft.fr...
tout d'abord merci pour vos réponses je vous confirme donc que ma vitesse d'emission est bien de 550Kbits (je sais patrick que c cette vitesse qu'il me faudrait accelerer mais c le meilleur abo dispo dans ma ville (debimax wanadoo)) j'ai utilisé au maxi les requettes et autres trucs conseillés en c/s. mais la question ke je me pose est : Est ce ke le moteur manta utilise bien tte la bande passante dispo ? tout est-il optimisé au niveau du routeur etc ... merci pour vos infos... "sebastien cabanes" <bedarieux.bureau.seb@wanadoo.fr> a écrit dans le message de news: 43bea388$1@news.pcsoft.fr... j'utilise un appli en C/S par adsl ma vitesse d'émission est de 550kb
le utilisateurs distants ne sont pas satisfaits de la vitesse de l'appli
connaissez-vous un moyen d'accellerer manta ? je dispose d'un serveur
sous windows et d'un autre sous linux en mandriva 2006. j'ai essayé les 2, la
vitesse est la même...
manta exploite t'il tout la bande passante ? y'a t'il un réglage à faire
au niveau du routeur ? quelles solutions avez vous essayé ?
|
| |
| |
| | | |
|
| | |
| |
Posté le 09 janvier 2006 - 15:54 |
Je reviens à mes 550 kbitshk0/sec...c'est fort lent...
En ce qui concerne les tables
tu fait avant remplissage de la table un matable..visible=faux
tu peux faire un pseudo fetch (si tu remplis avec une boucle, quand le nombre de ligne correspondant aux lignes visibles de la table est rempli, tu fais un multitache()
Tu vires les ascenceurs proportionnels
Tu n'actives les calculs bas de table qu'après le remplissage
A+ |
| |
| |
| | | |
|
| | |
| |
Posté le 10 janvier 2006 - 09:47 |
Ok, tu as une table liée à une requête décrite sous l'éditeur c'est bien ça?
La taille du fichier sur lequel tu travailles importe relativement peu car la requête s'exécute coté serveur par le biais du process manta.
Le problème c'est que le serveur va devoir retourner les enregistrements à l'application cliente (le resultset quoi). Et si la requete retourne 20'000 enregistrements, ce sont pas moins de 20'000 lignes qui devront transiter par la connexion pour être chargés en mémoire sur la machine courante comme ça d'un coup ou presque.
Avantage : une fois le téléchargement terminé, la table est super fluide, triable, loupe hyper rapide et tout et tout car vous bossez en mémoire!!
Désavantage : le téléchargement du résultat est lent
En revanche, sur un parcours fichier, donc en ayant lié la table au fichier HF, seuls les 20-30 lignes affichées à la fois + un petit cache seront retournées, et selon le mouvement de l'ascenseur, les autres lignes seront retournées par paquet de 30-40 A LA DEMANDE.
Pour les critères de sélection, faudra utiliser la fonction HFiltre sur le fichier concerné ( Me regardez pas comme ça, moi aussi je déteste cette fonction !!!  ), et si ça rame à mort, il faudra utiliser un ascenseur à rebond (non proportionnel) !
Voici un exemple code d'initialisation de table fichier
sCle est une chaine = hfiltre( sFichier, "truc=0 ET machin='chose' ")
//vous aurez de meilleurs résultat si vous laissez HF/CS choisir la clé de parcours
table..rubriqueparcourue = sCle
tableaffiche(table)
Avantage : moins longtemps à attendre puisque le fetch est partiel
Désavantage : la table est pas super confortable, les options de recherche limitées !
Alors la solution ? Essayez les 2 méthodes et prenez la plus satisfaisante selon vos résultats, si la table fichier, censée être la plus rapide vous donne un résultat à peine mieux que la requete, faites un choix...
Mais perso, j ai travaillé avec des table fichier à distance avec une connexion de 300kbits et sans être super fluide, c'etait admissible. |
| |
| |
| | | |
|
| | |
| |
Posté le 10 janvier 2006 - 10:26 |
merci pour ta réponse steph, je v tester ca et je te tiens au courrant
"_stef" <info@rmiconcept.ch> a écrit dans le message de news:
43c2c026$1@news.pcsoft.fr...
Ok, tu as une table liée à une requête décrite sous l'éditeur c'est bien ça? La taille du fichier sur lequel tu travailles importe relativement peu car la requête s'exécute coté serveur par le biais du process manta. Le problème c'est que le serveur va devoir retourner les enregistrements à l'application cliente (le resultset quoi). Et si la requete retourne 20'000 enregistrements, ce sont pas moins de 20'000 lignes qui devront transiter par la connexion pour être chargés en mémoire sur la machine courante comme ça d'un coup ou presque. Avantage : une fois le téléchargement terminé, la table est super fluide, triable, loupe hyper rapide et tout et tout car vous bossez en mémoire!! Désavantage : le téléchargement du résultat est lent En revanche, sur un parcours fichier, donc en ayant lié la table au fichier HF, seuls les 20-30 lignes affichées à la fois + un petit cache seront retournées, et selon le mouvement de l'ascenseur, les autres lignes seront retournées par paquet de 30-40 A LA DEMANDE. Pour les critères de sélection, faudra utiliser la fonction HFiltre sur le fichier concerné ( Me regardez pas comme ça, moi aussi je déteste cette fonction !!! ), et si ça rame à mort, il faudra utiliser un ascenseur à rebond (non proportionnel) ! Voici un exemple code d'initialisation de table fichier sCle est une chaine = hfiltre( sFichier, "truc=0 ET machin='chose' ") //vous aurez de meilleurs résultat si vous laissez HF/CS choisir la clé de parcours table..rubriqueparcourue = sCle tableaffiche(table) Avantage : moins longtemps à attendre puisque le fetch est partiel Désavantage : la table est pas super confortable, les options de recherche limitées ! Alors la solution ? Essayez les 2 méthodes et prenez la plus satisfaisante selon vos résultats, si la table fichier, censée être la plus rapide vous donne un résultat à peine mieux que la requete, faites un choix... Mais perso, j ai travaillé avec des table fichier à distance avec une connexion de 300kbits et sans être super fluide, c'etait admissible. |
| |
| |
| | | |
|
| | |
| |
Posté le 10 janvier 2006 - 19:49 |
sebastien cabanes avait écrit le 10/01/2006 :
merci pour ta réponse steph, je v tester ca et je te tiens au courrant "_stef" <info@rmiconcept.ch> a écrit dans le message de news: 43c2c026$1@news.pcsoft.fr... Ok, tu as une table liée à une requête décrite sous l'éditeur c'est bien ça? La taille du fichier sur lequel tu travailles importe relativement peu car la requête s'exécute coté serveur par le biais du process manta. Le problème c'est que le serveur va devoir retourner les enregistrements à l'application cliente (le resultset quoi). Et si la requete retourne 20'000 enregistrements, ce sont pas moins de 20'000 lignes qui devront transiter par la connexion pour être chargés en mémoire sur la machine courante comme ça d'un coup ou presque. Avantage : une fois le téléchargement terminé, la table est super fluide, triable, loupe hyper rapide et tout et tout car vous bossez en mémoire!! Désavantage : le téléchargement du résultat est lent En revanche, sur un parcours fichier, donc en ayant lié la table au fichier HF, seuls les 20-30 lignes affichées à la fois + un petit cache seront retournées, et selon le mouvement de l'ascenseur, les autres lignes seront retournées par paquet de 30-40 A LA DEMANDE. Pour les critères de sélection, faudra utiliser la fonction HFiltre sur le fichier concerné ( Me regardez pas comme ça, moi aussi je déteste cette fonction !!! ), et si ça rame à mort, il faudra utiliser un ascenseur à rebond (non proportionnel) ! Voici un exemple code d'initialisation de table fichier sCle est une chaine = hfiltre( sFichier, "truc=0 ET machin='chose' ") //vous aurez de meilleurs résultat si vous laissez HF/CS choisir la clé de parcours table..rubriqueparcourue = sCle tableaffiche(table) Avantage : moins longtemps à attendre puisque le fetch est partiel Désavantage : la table est pas super confortable, les options de recherche limitées ! Alors la solution ? Essayez les 2 méthodes et prenez la plus satisfaisante selon vos résultats, si la table fichier, censée être la plus rapide vous donne un résultat à peine mieux que la requete, faites un choix... Mais perso, j ai travaillé avec des table fichier à distance avec une connexion de 300kbits et sans être super fluide, c'etait admissible.
Tu peux aussi créer une requête qui ne retoune que par série de 1000
enregistrements...D'abort 1--> 1000 puis 1001 --> 2000....
A voir
A+
--
Dr J-M des Grottes
Gestionnaire du Registre des Néphrologues Francophones de Belgique |
| |
| |
| | | |
|
| | |
| |
Posté le 11 janvier 2006 - 10:39 |
j'ai déjà essayé (si on parle de la meme chose) de limiter le nombre de
retours à 30 (dans l'éditeur de requetes avec l'option "n premiers" cela n'a
rien changé à la vitesse
y'a t'il un autre moyen ?
merci
"J-M des Grottes" <jmdg@easynet.be> a écrit dans le message de news:
mn.546a7d61af4f3b15.28828@easynet.be...
sebastien cabanes avait écrit le 10/01/2006 : merci pour ta réponse steph, je v tester ca et je te tiens au courrant "_stef" <info@rmiconcept.ch> a écrit dans le message de news: 43c2c026$1@news.pcsoft.fr... Ok, tu as une table liée à une requête décrite sous l'éditeur c'est bien ça? La taille du fichier sur lequel tu travailles importe relativement peu car la requête s'exécute coté serveur par le biais du process manta. Le problème c'est que le serveur va devoir retourner les enregistrements à l'application cliente (le resultset quoi). Et si la requete retourne 20'000 enregistrements, ce sont pas moins de 20'000 lignes qui devront transiter par la connexion pour être chargés en mémoire sur la machine courante comme ça d'un coup ou presque. Avantage : une fois le téléchargement terminé, la table est super fluide, triable, loupe hyper rapide et tout et tout car vous bossez en mémoire!! Désavantage : le téléchargement du résultat est lent En revanche, sur un parcours fichier, donc en ayant lié la table au fichier HF, seuls les 20-30 lignes affichées à la fois + un petit cache seront retournées, et selon le mouvement de l'ascenseur, les autres lignes seront retournées par paquet de 30-40 A LA DEMANDE. Pour les critères de sélection, faudra utiliser la fonction HFiltre sur le fichier concerné ( Me regardez pas comme ça, moi aussi je déteste cette fonction !!! ), et si ça rame à mort, il faudra utiliser un ascenseur à rebond (non proportionnel) ! Voici un exemple code d'initialisation de table fichier sCle est une chaine = hfiltre( sFichier, "truc=0 ET machin='chose' ") //vous aurez de meilleurs résultat si vous laissez HF/CS choisir la clé de parcours table..rubriqueparcourue = sCle tableaffiche(table) Avantage : moins longtemps à attendre puisque le fetch est partiel Désavantage : la table est pas super confortable, les options de recherche limitées ! Alors la solution ? Essayez les 2 méthodes et prenez la plus satisfaisante selon vos résultats, si la table fichier, censée être la plus rapide vous donne un résultat à peine mieux que la requete, faites un choix... Mais perso, j ai travaillé avec des table fichier à distance avec une connexion de 300kbits et sans être super fluide, c'etait admissible. Tu peux aussi créer une requête qui ne retoune que par série de 1000 enregistrements...D'abort 1--> 1000 puis 1001 --> 2000.... A voir A+ -- Dr J-M des Grottes Gestionnaire du Registre des Néphrologues Francophones de Belgique |
| |
| |
| | | |
|
| | |
| |
Posté le 11 janvier 2006 - 17:53 |
sebastien cabanes a écrit :
j'ai déjà essayé (si on parle de la meme chose) de limiter le nombre de retours à 30 (dans l'éditeur de requetes avec l'option "n premiers" cela n'a rien changé à la vitesse y'a t'il un autre moyen ? merci "J-M des Grottes" <jmdg@easynet.be> a écrit dans le message de news: mn.546a7d61af4f3b15.28828@easynet.be... sebastien cabanes avait écrit le 10/01/2006 : merci pour ta réponse steph, je v tester ca et je te tiens au courrant "_stef" <info@rmiconcept.ch> a écrit dans le message de news: 43c2c026$1@news.pcsoft.fr... Ok, tu as une table liée à une requête décrite sous l'éditeur c'est bien ça? La taille du fichier sur lequel tu travailles importe relativement peu car la requête s'exécute coté serveur par le biais du process manta. Le problème c'est que le serveur va devoir retourner les enregistrements à l'application cliente (le resultset quoi). Et si la requete retourne 20'000 enregistrements, ce sont pas moins de 20'000 lignes qui devront transiter par la connexion pour être chargés en mémoire sur la machine courante comme ça d'un coup ou presque. Avantage : une fois le téléchargement terminé, la table est super fluide, triable, loupe hyper rapide et tout et tout car vous bossez en mémoire!! Désavantage : le téléchargement du résultat est lent En revanche, sur un parcours fichier, donc en ayant lié la table au fichier HF, seuls les 20-30 lignes affichées à la fois + un petit cache seront retournées, et selon le mouvement de l'ascenseur, les autres lignes seront retournées par paquet de 30-40 A LA DEMANDE. Pour les critères de sélection, faudra utiliser la fonction HFiltre sur le fichier concerné ( Me regardez pas comme ça, moi aussi je déteste cette fonction !!! ), et si ça rame à mort, il faudra utiliser un ascenseur à rebond (non proportionnel) ! Voici un exemple code d'initialisation de table fichier sCle est une chaine = hfiltre( sFichier, "truc=0 ET machin='chose' ") //vous aurez de meilleurs résultat si vous laissez HF/CS choisir la clé de parcours table..rubriqueparcourue = sCle tableaffiche(table) Avantage : moins longtemps à attendre puisque le fetch est partiel Désavantage : la table est pas super confortable, les options de recherche limitées ! Alors la solution ? Essayez les 2 méthodes et prenez la plus satisfaisante selon vos résultats, si la table fichier, censée être la plus rapide vous donne un résultat à peine mieux que la requete, faites un choix... Mais perso, j ai travaillé avec des table fichier à distance avec une connexion de 300kbits et sans être super fluide, c'etait admissible. Tu peux aussi créer une requête qui ne retoune que par série de 1000 enregistrements...D'abort 1--> 1000 puis 1001 --> 2000.... A voir A+ -- Dr J-M des Grottes Gestionnaire du Registre des Néphrologues Francophones de Belgique
2 choses peuvent jouer
1) le nombre d'échanges entre ton PC et le serveur
2) la quantité réelle d'information qui transite. Un enregistrement
contenant une image est plus lent à arriver que 20 enregistrements -
lourds...
Vérifie le type d'info qui transite, le nombre de demande...
N'y a t'il pas des info annexes qui prennent des octets de trop....
Maintenant il n'y a pas de secret 60 ko...
Un autre test est de mettre ta configuration sur réseau local. Si le
problème persiste c'est que cela ne vient pas de ta vitesse...
Tiens moi au courant
A+
--
Dr J-M des Grottes
Gestionnaire du Registre des Néphrologues Francophones de Belgique |
| |
| |
| | | |
|
| | |
| |
Posté le 11 janvier 2006 - 18:32 |
Mon appli tourne en réso local et en adsl (j'ai 2 points de vente) en réso
local, aucun probleme, vraiment aucun, par contre, depuis le passage en w10,
les utilisateurs par adsl souffrent.pourtant il n'y a aucune image, que du
texte et c un fichier article donc c pas un roman koi. Je sais que 60Ko c
tres lent, mais nous ne sommes pas en zone dégroupée et c le mieux que nous
pouvons avoir (hormis lignes dédiées hors de prix ou hébergement sur serveur
dédié distant) c la raison pour laquelle je cherches à optimiser au maximum
le c/s. j'attends donc pour l'instant une prochaine mise à jour de Wd10,
sinon je serai obligé de faire 2 serveurs et de la réplication.
merci pour le temps ke tu m'as accordé, et si entre temps tu as d'autres
idées, je te laisse mon mail : calipage2@wanadoo.fr
merci
"J-M des Grottes" <jmdg@easynet.be> a écrit dans le message de news:
mn.5bc67d6173916cd3.28828@easynet.be...
sebastien cabanes a écrit : j'ai déjà essayé (si on parle de la meme chose) de limiter le nombre de retours à 30 (dans l'éditeur de requetes avec l'option "n premiers" cela n'a rien changé à la vitesse y'a t'il un autre moyen ? merci "J-M des Grottes" <jmdg@easynet.be> a écrit dans le message de news: mn.546a7d61af4f3b15.28828@easynet.be... sebastien cabanes avait écrit le 10/01/2006 : merci pour ta réponse steph, je v tester ca et je te tiens au courrant "_stef" <info@rmiconcept.ch> a écrit dans le message de news: 43c2c026$1@news.pcsoft.fr... Ok, tu as une table liée à une requête décrite sous l'éditeur c'est bien ça? La taille du fichier sur lequel tu travailles importe relativement peu car la requête s'exécute coté serveur par le biais du process manta. Le problème c'est que le serveur va devoir retourner les enregistrements à l'application cliente (le resultset quoi). Et si la requete retourne 20'000 enregistrements, ce sont pas moins de 20'000 lignes qui devront transiter par la connexion pour être chargés en mémoire sur la machine courante comme ça d'un coup ou presque. Avantage : une fois le téléchargement terminé, la table est super fluide, triable, loupe hyper rapide et tout et tout car vous bossez en mémoire!! Désavantage : le téléchargement du résultat est lent En revanche, sur un parcours fichier, donc en ayant lié la table au fichier HF, seuls les 20-30 lignes affichées à la fois + un petit cache seront retournées, et selon le mouvement de l'ascenseur, les autres lignes seront retournées par paquet de 30-40 A LA DEMANDE. Pour les critères de sélection, faudra utiliser la fonction HFiltre sur le fichier concerné ( Me regardez pas comme ça, moi aussi je déteste cette fonction !!! ), et si ça rame à mort, il faudra utiliser un ascenseur à rebond (non proportionnel) ! Voici un exemple code d'initialisation de table fichier sCle est une chaine = hfiltre( sFichier, "truc=0 ET machin='chose' ") //vous aurez de meilleurs résultat si vous laissez HF/CS choisir la clé de parcours table..rubriqueparcourue = sCle tableaffiche(table) Avantage : moins longtemps à attendre puisque le fetch est partiel Désavantage : la table est pas super confortable, les options de recherche limitées ! Alors la solution ? Essayez les 2 méthodes et prenez la plus satisfaisante selon vos résultats, si la table fichier, censée être la plus rapide vous donne un résultat à peine mieux que la requete, faites un choix... Mais perso, j ai travaillé avec des table fichier à distance avec une connexion de 300kbits et sans être super fluide, c'etait admissible. Tu peux aussi créer une requête qui ne retoune que par série de 1000 enregistrements...D'abort 1--> 1000 puis 1001 --> 2000.... A voir A+ -- Dr J-M des Grottes Gestionnaire du Registre des Néphrologues Francophones de Belgique 2 choses peuvent jouer 1) le nombre d'échanges entre ton PC et le serveur 2) la quantité réelle d'information qui transite. Un enregistrement contenant une image est plus lent à arriver que 20 enregistrements - lourds... Vérifie le type d'info qui transite, le nombre de demande... N'y a t'il pas des info annexes qui prennent des octets de trop.... Maintenant il n'y a pas de secret 60 ko... Un autre test est de mettre ta configuration sur réseau local. Si le problème persiste c'est que cela ne vient pas de ta vitesse... Tiens moi au courant A+ -- Dr J-M des Grottes Gestionnaire du Registre des Néphrologues Francophones de Belgique |
| |
| |
| | | |
|
| | |
| |
Posté le 11 janvier 2006 - 20:57 |
Le 11/01/2006, sebastien cabanes a supposé :
Mon appli tourne en réso local et en adsl (j'ai 2 points de vente) en réso local, aucun probleme, vraiment aucun, par contre, depuis le passage en w10, les utilisateurs par adsl souffrent.pourtant il n'y a aucune image, que du texte et c un fichier article donc c pas un roman koi. Je sais que 60Ko c tres lent, mais nous ne sommes pas en zone dégroupée et c le mieux que nous pouvons avoir (hormis lignes dédiées hors de prix ou hébergement sur serveur dédié distant) c la raison pour laquelle je cherches à optimiser au maximum le c/s. j'attends donc pour l'instant une prochaine mise à jour de Wd10, sinon je serai obligé de faire 2 serveurs et de la réplication. merci pour le temps ke tu m'as accordé, et si entre temps tu as d'autres idées, je te laisse mon mail : calipage2@wanadoo.fr merci "J-M des Grottes" <jmdg@easynet.be> a écrit dans le message de news: mn.5bc67d6173916cd3.28828@easynet.be... sebastien cabanes a écrit : j'ai déjà essayé (si on parle de la meme chose) de limiter le nombre de retours à 30 (dans l'éditeur de requetes avec l'option "n premiers" cela n'a rien changé à la vitesse y'a t'il un autre moyen ? merci "J-M des Grottes" <jmdg@easynet.be> a écrit dans le message de news: mn.546a7d61af4f3b15.28828@easynet.be... sebastien cabanes avait écrit le 10/01/2006 : merci pour ta réponse steph, je v tester ca et je te tiens au courrant "_stef" <info@rmiconcept.ch> a écrit dans le message de news: 43c2c026$1@news.pcsoft.fr... Ok, tu as une table liée à une requête décrite sous l'éditeur c'est bien ça? La taille du fichier sur lequel tu travailles importe relativement peu car la requête s'exécute coté serveur par le biais du process manta. Le problème c'est que le serveur va devoir retourner les enregistrements à l'application cliente (le resultset quoi). Et si la requete retourne 20'000 enregistrements, ce sont pas moins de 20'000 lignes qui devront transiter par la connexion pour être chargés en mémoire sur la machine courante comme ça d'un coup ou presque. Avantage : une fois le téléchargement terminé, la table est super fluide, triable, loupe hyper rapide et tout et tout car vous bossez en mémoire!! Désavantage : le téléchargement du résultat est lent En revanche, sur un parcours fichier, donc en ayant lié la table au fichier HF, seuls les 20-30 lignes affichées à la fois + un petit cache seront retournées, et selon le mouvement de l'ascenseur, les autres lignes seront retournées par paquet de 30-40 A LA DEMANDE. Pour les critères de sélection, faudra utiliser la fonction HFiltre sur le fichier concerné ( Me regardez pas comme ça, moi aussi je déteste cette fonction !!! ), et si ça rame à mort, il faudra utiliser un ascenseur à rebond (non proportionnel) ! Voici un exemple code d'initialisation de table fichier sCle est une chaine = hfiltre( sFichier, "truc=0 ET machin='chose' ") //vous aurez de meilleurs résultat si vous laissez HF/CS choisir la clé de parcours table..rubriqueparcourue = sCle tableaffiche(table) Avantage : moins longtemps à attendre puisque le fetch est partiel Désavantage : la table est pas super confortable, les options de recherche limitées ! Alors la solution ? Essayez les 2 méthodes et prenez la plus satisfaisante selon vos résultats, si la table fichier, censée être la plus rapide vous donne un résultat à peine mieux que la requete, faites un choix... Mais perso, j ai travaillé avec des table fichier à distance avec une connexion de 300kbits et sans être super fluide, c'etait admissible. Tu peux aussi créer une requête qui ne retoune que par série de 1000 enregistrements...D'abort 1--> 1000 puis 1001 --> 2000.... A voir A+ -- Dr J-M des Grottes Gestionnaire du Registre des Néphrologues Francophones de Belgique 2 choses peuvent jouer 1) le nombre d'échanges entre ton PC et le serveur 2) la quantité réelle d'information qui transite. Un enregistrement contenant une image est plus lent à arriver que 20 enregistrements - lourds... Vérifie le type d'info qui transite, le nombre de demande... N'y a t'il pas des info annexes qui prennent des octets de trop.... Maintenant il n'y a pas de secret 60 ko... Un autre test est de mettre ta configuration sur réseau local. Si le problème persiste c'est que cela ne vient pas de ta vitesse... Tiens moi au courant A+ -- Dr J-M des Grottes Gestionnaire du Registre des Néphrologues Francophones de Belgique
Oui je pense à toi car je vais devoir faire même genre de truc mais
avec ul ligne à 2 Mbit..On verra...
--
Dr J-M des Grottes
Gestionnaire du Registre des Néphrologues Francophones de Belgique |
| |
| |
| | | |
|
| | |
| |
Posté le 11 janvier 2006 - 20:57 |
sebastien cabanes a exprimé avec précision :
Mon appli tourne en réso local et en adsl (j'ai 2 points de vente) en réso local, aucun probleme, vraiment aucun, par contre, depuis le passage en w10, les utilisateurs par adsl souffrent.pourtant il n'y a aucune image, que du texte et c un fichier article donc c pas un roman koi. Je sais que 60Ko c tres lent, mais nous ne sommes pas en zone dégroupée et c le mieux que nous pouvons avoir (hormis lignes dédiées hors de prix ou hébergement sur serveur dédié distant) c la raison pour laquelle je cherches à optimiser au maximum le c/s. j'attends donc pour l'instant une prochaine mise à jour de Wd10, sinon je serai obligé de faire 2 serveurs et de la réplication. merci pour le temps ke tu m'as accordé, et si entre temps tu as d'autres idées, je te laisse mon mail : calipage2@wanadoo.fr merci "J-M des Grottes" <jmdg@easynet.be> a écrit dans le message de news: mn.5bc67d6173916cd3.28828@easynet.be... sebastien cabanes a écrit : j'ai déjà essayé (si on parle de la meme chose) de limiter le nombre de retours à 30 (dans l'éditeur de requetes avec l'option "n premiers" cela n'a rien changé à la vitesse y'a t'il un autre moyen ? merci "J-M des Grottes" <jmdg@easynet.be> a écrit dans le message de news: mn.546a7d61af4f3b15.28828@easynet.be... sebastien cabanes avait écrit le 10/01/2006 : merci pour ta réponse steph, je v tester ca et je te tiens au courrant "_stef" <info@rmiconcept.ch> a écrit dans le message de news: 43c2c026$1@news.pcsoft.fr... Ok, tu as une table liée à une requête décrite sous l'éditeur c'est bien ça? La taille du fichier sur lequel tu travailles importe relativement peu car la requête s'exécute coté serveur par le biais du process manta. Le problème c'est que le serveur va devoir retourner les enregistrements à l'application cliente (le resultset quoi). Et si la requete retourne 20'000 enregistrements, ce sont pas moins de 20'000 lignes qui devront transiter par la connexion pour être chargés en mémoire sur la machine courante comme ça d'un coup ou presque. Avantage : une fois le téléchargement terminé, la table est super fluide, triable, loupe hyper rapide et tout et tout car vous bossez en mémoire!! Désavantage : le téléchargement du résultat est lent En revanche, sur un parcours fichier, donc en ayant lié la table au fichier HF, seuls les 20-30 lignes affichées à la fois + un petit cache seront retournées, et selon le mouvement de l'ascenseur, les autres lignes seront retournées par paquet de 30-40 A LA DEMANDE. Pour les critères de sélection, faudra utiliser la fonction HFiltre sur le fichier concerné ( Me regardez pas comme ça, moi aussi je déteste cette fonction !!! ), et si ça rame à mort, il faudra utiliser un ascenseur à rebond (non proportionnel) ! Voici un exemple code d'initialisation de table fichier sCle est une chaine = hfiltre( sFichier, "truc=0 ET machin='chose' ") //vous aurez de meilleurs résultat si vous laissez HF/CS choisir la clé de parcours table..rubriqueparcourue = sCle tableaffiche(table) Avantage : moins longtemps à attendre puisque le fetch est partiel Désavantage : la table est pas super confortable, les options de recherche limitées ! Alors la solution ? Essayez les 2 méthodes et prenez la plus satisfaisante selon vos résultats, si la table fichier, censée être la plus rapide vous donne un résultat à peine mieux que la requete, faites un choix... Mais perso, j ai travaillé avec des table fichier à distance avec une connexion de 300kbits et sans être super fluide, c'etait admissible. Tu peux aussi créer une requête qui ne retoune que par série de 1000 enregistrements...D'abort 1--> 1000 puis 1001 --> 2000.... A voir A+ -- Dr J-M des Grottes Gestionnaire du Registre des Néphrologues Francophones de Belgique 2 choses peuvent jouer 1) le nombre d'échanges entre ton PC et le serveur 2) la quantité réelle d'information qui transite. Un enregistrement contenant une image est plus lent à arriver que 20 enregistrements - lourds... Vérifie le type d'info qui transite, le nombre de demande... N'y a t'il pas des info annexes qui prennent des octets de trop.... Maintenant il n'y a pas de secret 60 ko... Un autre test est de mettre ta configuration sur réseau local. Si le problème persiste c'est que cela ne vient pas de ta vitesse... Tiens moi au courant A+ -- Dr J-M des Grottes Gestionnaire du Registre des Néphrologues Francophones de Belgique
Autre truc: Pompe tes 40000 enregistrements dans un fichier local.
Travaille directement sur le fichier local.
Tout dépend de tes traitements. Si ce n'est que de la
consultation...cela marche.
A voir quoi
Bon dev
--
Dr J-M des Grottes
Gestionnaire du Registre des Néphrologues Francophones de Belgique |
| |
| |
| | | |
|
| | | | |
| | |
| | |
| |
|
|
|