[MySQL] Améliorer la vitesse pour les parcours

jacques trepp

19/08/2004 à 10:30

Romain PETIT wrote:

Bonjour,

en pleine phase d'étude pour un transfert HF7->MySQL avec les accès
(alter)natifs, je suis au premier abord un peu déçu par la vitesse des
parcours de fichier :

NOMTEST est une clé texte sur 20 (avec doublon)
parcours de 147 enregistrements sur 8286
Les 2 bases sont sur la même machine (XP SP1) et accédée via le réseau
par la machine de développement (XP SP1).
MySQL version 4.020a-nt-max

***********Code HF
c=0
HRAZ(TEST)
HFiltre(TEST,NOMTEST,"INR","INR")
HLitPremier(TEST,NOMTEST)
TANTQUE PAS HEnDehors
c++
Trace(c+" -"+TEST.NOMTEST)
HLitSuivant(TEST,NOMTEST)
FIN

***********Code MySQL (via SQLManagerX)
c=0
oTEST:SQLRaz()
oTEST:SQLfiltre("NOMTEST='INR'")
oTEST:SQLPremier()
TANTQUE PAS oTEST:endehors
c++
Trace(c+" -"+oTEST:m_NOMTEST)
oTEST:SQlSuivant()
FIN

HF -> en moyenne 1 sec 20
MySQL -> en moyenne 5 sec 40

HF est 4 à 5 fois plus rapide...
Bien sûr, je concois que ce n'est pas la bonne façon pour utiliser
MySQL et évidemment, je vais dans un second temps tester une
programmation plus adapté à un vrai moteur SGDB mais y-a-t-il quand
même un moyen d'améliorer ce type de parcours (j'ai beaucoup de
parcours dans une appli que je voudrais migrer) ?

A+

Bonjour,
qu'en est-il des index ? NOMTEST est-il un index ?
Frédéric recommande souvent d'encadrer les requètes dans une transaction.
En production, je n'utilise le parcours "à la HF" que dans des cas
particuliers :
Mode fiche, en création ou modif.
Recherche d'un libellé (style cherche le libellé du code règlement N° 12),
car ça évite le fetch :
REG:SQLLitRecherche( "CODEREG = 12")
libellé_reg = REG:m_LIBREG
fastoche.
Pour tout le reste, je privilégie les requètes en envoyant le résultat dans
une table mémoire.
c'est plus rapide et plus puissant.

Cordialement

--
Jacques TREPP
AlbyGest

enlever _pasdespam pour me joindre

Romain PETIT

19/08/2004 à 10:51

jacques trepp a émis l'idée suivante :

Bonjour,
qu'en est-il des index ? NOMTEST est-il un index ?

Oui.
La base a été migrée à partir des outils SQLManagerX.

Frédéric recommande souvent d'encadrer les requètes dans une transaction.
En production, je n'utilise le parcours "à la HF" que dans des cas
particuliers :

Oui, je sais que le parcours à la HF n'est pas à privilégier avec MySQL
mais comme je l'ai dit dans mon 1er post, il s'agit pour moi de migrer
progressivement l'existant, donc sans revoir de fond en comble les
méthodes de programmation d'une application spécifiquement prévue pour
du HF.
En ayant lu la doc de SQLManagerX, je m'attendais à bien à ce que MySQL
pèche un peu sur les parcours à la HF, mais de là à être 5 fois plus
lent...

Pour tout le reste, je privilégie les requètes en envoyant le résultat dans
une table mémoire.
c'est plus rapide et plus puissant.

Oui et heureusement car c'est ce qui m'incite à vouloir migrer mon
application : j'utilise des vues HF dans la partie la plus importante
pour l'utilisateur et ces vues sont de plus en plus lentes au fur et à
mesure que la base grossie...

A+

--
Romain PETIT
http://cerbermail.com/?IJmancZl88
(cliquez sur le lien ci-dessus pour me contacter en privé)

Romuald.besset

19/08/2004 à 11:41

Romain PETIT wrote:

jacques trepp a émis l'idée suivante :

Bonjour,
qu'en est-il des index ? NOMTEST est-il un index ?

Oui.
La base a été migrée à partir des outils SQLManagerX.

Frédéric recommande souvent d'encadrer les requètes dans une transaction.
En production, je n'utilise le parcours "à la HF" que dans des cas
particuliers :

Oui, je sais que le parcours à la HF n'est pas à privilégier avec MySQL
mais comme je l'ai dit dans mon 1er post, il s'agit pour moi de migrer
progressivement l'existant, donc sans revoir de fond en comble les
méthodes de programmation d'une application spécifiquement prévue pour
du HF.
En ayant lu la doc de SQLManagerX, je m'attendais à bien à ce que MySQL
pèche un peu sur les parcours à la HF, mais de là à être 5 fois plus
lent...

Pour tout le reste, je privilégie les requètes en envoyant le résultat
dans
une table mémoire.
c'est plus rapide et plus puissant.

Oui et heureusement car c'est ce qui m'incite à vouloir migrer mon
application : j'utilise des vues HF dans la partie la plus importante
pour l'utilisateur et ces vues sont de plus en plus lentes au fur et à
mesure que la base grossie...

A+

Sur ce point des parcours WinDev + HF sont trés performant... il va être
difficile d'avoir la même chose en sql.
C'est sur le reste des traitments "SQL" que les gains s'opèrent !

++ R&B

Manu

19/08/2004 à 11:46

> en pleine phase d'étude pour un transfert HF7->MySQL avec les accès
(alter)natifs, je suis au premier abord un peu déçu par la vitesse des
parcours de fichier :

[CUT]

***********Code MySQL (via SQLManagerX)
c=0
oTEST:SQLRaz()
oTEST:SQLfiltre("NOMTEST='INR'")
oTEST:SQLPremier()
TANTQUE PAS oTEST:endehors
c++
Trace(c+" -"+oTEST:m_NOMTEST)
oTEST:SQlSuivant()
FIN

HF -> en moyenne 1 sec 20
MySQL -> en moyenne 5 sec 40

HF est 4 à 5 fois plus rapide...

Oui, mais : tu es en local et mono utilisateur. Je peux t'assurer que le
temps constater avec SQLManagerX (ou plustot MySQL) sera identique quelque
soit le nombre d'utilisateurs et même en déporté (dans ce cas là il faut
bien sur ajouter le temsp de transport de l'information).

Bien sûr, je concois que ce n'est pas la bonne façon pour utiliser
MySQL et évidemment, je vais dans un second temps tester une
programmation plus adapté à un vrai moteur SGDB mais y-a-t-il quand
même un moyen d'améliorer ce type de parcours (j'ai beaucoup de
parcours dans une appli que je voudrais migrer) ?

Si et Firetox travaille dessus. Si j'ai bien compris le mode parcours de
SQLManagerX gére à chaque appel Suivant la fonction limit dans la requete ce
qui ajoute donc un temps en plus.

A+

Romain PETIT

19/08/2004 à 13:05

Manu vient de nous annoncer :

HF est 4 à 5 fois plus rapide...

Oui, mais : tu es en local

Non, les 2 bases HF et MySQL sont sur une machine du réseau, la même.

et mono utilisateur. Je peux t'assurer que le
temps constater avec SQLManagerX (ou plustot MySQL) sera identique quelque
soit le nombre d'utilisateurs et même en déporté (dans ce cas là il faut
bien sur ajouter le temsp de transport de l'information).

Ok.

y-a-t-il quand
même un moyen d'améliorer ce type de parcours ?

Si et Firetox travaille dessus. Si j'ai bien compris le mode parcours de
SQLManagerX gére à chaque appel Suivant la fonction limit dans la requete ce
qui ajoute donc un temps en plus.

Vivement la nouvelle version... :-)
Je retourne à mes tests (et encore bravo à toute l'équipe pour tout le
chemin accompli)

A+

--
Romain PETIT
http://cerbermail.com/?IJmancZl88
(cliquez sur le lien ci-dessus pour me contacter en privé)

Daniel

19/08/2004 à 22:20

Bonsoir,

effectivement la sélection avec sqlfiltre et sqlsuivant est beaucoup
plus longue. chaque sqlsuivant relance la requête "select
* from test where nomtest='INR'" avec un limit 1 pour récupérer une
seule valeur.

Un test sur 100 000 enregistrement avec un retour de 1000 lignes me
donne :
en HF (en réseau) 1 sec 40
en Mysql SQLX 10 sec
en Mysql avec Mysql4WD 1 sec 30

Bien entendu ce test n'est pas vraiment représentatif, car on compare
une base réseau pour lequel le travail est fait par l'applicatif, et
un SGBD pour lequel le serveur renvoie uniquement le résultat. Le test
que j'ai fait est sur un réseau 100BaseT, avec une petite table...

Je viens de faire un Dump sur le port 3306(mysql) et 139(netbios) bon il y a pas photo
sans rentrer dans les détail :
avec mysql4wd : 10 paquets
avec SQLX : 6000 paquets
avec HF: 154

Toutefois en regardant de plus près le contenu des trames on voit bien
que sur Mysql en retour circule uniquement "INR", par contre en HF on
a toutes les données...

Donc Mysql est aussi rapide, même plus rapide que HF (en condition
réelle), parcontre certaines opérations avec SQLXmanager sont plus
longues.

Personnellement j'utilise les commandes mysqlexec... pour les select,
et toutes les commandes SQLXmanager pour les insert, et update.

Romain PETIT writes:

Bonjour,

en pleine phase d'étude pour un transfert HF7->MySQL avec les accès
(alter)natifs, je suis au premier abord un peu déçu par la vitesse des
parcours de fichier :

NOMTEST est une clé texte sur 20 (avec doublon)
parcours de 147 enregistrements sur 8286
Les 2 bases sont sur la même machine (XP SP1) et accédée via le r éseau
par la machine de développement (XP SP1).
MySQL version 4.020a-nt-max

***********Code HF
c=0
HRAZ(TEST)
HFiltre(TEST,NOMTEST,"INR","INR")
HLitPremier(TEST,NOMTEST)
TANTQUE PAS HEnDehors
c++
Trace(c+" -"+TEST.NOMTEST)
HLitSuivant(TEST,NOMTEST)
FIN

***********Code MySQL (via SQLManagerX)
c=0
oTEST:SQLRaz()
oTEST:SQLfiltre("NOMTEST='INR'")
oTEST:SQLPremier()
TANTQUE PAS oTEST:endehors
c++
Trace(c+" -"+oTEST:m_NOMTEST)
oTEST:SQlSuivant()
FIN

HF -> en moyenne 1 sec 20
MySQL -> en moyenne 5 sec 40

HF est 4 à 5 fois plus rapide...
Bien sûr, je concois que ce n'est pas la bonne façon pour utiliser
MySQL et évidemment, je vais dans un second temps tester une
programmation plus adapté à un vrai moteur SGDB mais y-a-t-il quand
même un moyen d'améliorer ce type de parcours (j'ai beaucoup de
parcours dans une appli que je voudrais migrer) ?

A+

--
Romain PETIT
http://cerbermail.com/?IJmancZl88
(cliquez sur le lien ci-dessus pour me contacter en privé)