Je cherche depuis plusieurs années (!) à trouver une solution aux lenteurs
hyperfile (pour la petite histoire, une appli en WD5.5 avec vues et ordres
h* donnait de très bon résultats en terme de performances; passée en 7.5,
puis 8 et aujourd'hui 9, les performances se sont écroulées... parfois
jusqu'à 70 fois plus lente)
Je cherche à améliorer ce code, qui ne fait que de lire une table (à partir
d'une requete) et transfere les 30 premières lignes dans une table mémoire.
Voici le code (ultra-simple):
lCond = "select REFDOC,IDDOCUMLG,DESIGNATION,'',0,0 from DOCUMLG where
IDDOCUM = 3892 order by IDDOCUMLG"
si sqlexec(lCond,"ReqI") alors
sqltable(30,"ReqI","TABLE")
fin
sqlferme("ReqI")
La table (donc les trente 1eres lignes) s'affiche, EN LOCAL, en plus de 12
secondes (assez "insupportable" pour les utilisateurs) !!!
Pourtant toutes les clés sont bien positionnées (IDDOCUM, IDDOCUMLG
primaire) et donc impossible, à mon avis, d'optimiser la requète (j'ai aussi
essayé en rendant la table invisible et divers autres astuces sans succès).
Le fichier (la table) comporte aujourd'hui 361000 tuples de longueur 299
octets et grossit en permanence (encore des inquiétudes !).
D'où mes questions:
Pensez vous qu'en HF C/S, ce sera mieux (notammment en réseau
multi-utilisateurs - rappel: essai fait en local) et de quel ordre ?
Dois je migrer en WD 10 (meilleures performances du moteur HF classic ?)
Faut-il vraiment que je migre la base vers MySQL par ex ?
Je ne pense pas que HF C/S apporterais une différence dans ce cas. Ce moteur est uniquement plus puissant pour les requêtes multi-fichiers (WD9).
c'est mal exprimé: il faudrait remplacer "uniquement" par "particulièrement".
Je ne pense non plus que WD10 apporterais une différence, car l'amélioration que j'ai noté est sur les requêtes multi-fichiers
sous HF Classic.
Ces derniers offrent maintenant à peu près la rapidité de HF C/S (sans pour autant arriver au niveau de produits concurrents).
Salutations Mat
Marc Benoit
Bonjour,
Tout à fait d'accord avec tout ce qui a été dit. Nous avons 4 sites distants, un serveur HF/CS sous linux et une requete, sur fichiers hyper file - 8 tables concernées, 30 000 à 35 000 enregs, jointures externes,... - mettait parfois 2 à 3 mn pour arriver La même requete en ordres H sur fichiers hf classiques environ 20 sec. en local et parfois 15 à 20 mn en distant
On a tout basculé en MySQL avec ordres SQL purs et durs : temps de réponse parfois divisé par 80 ...
Dés tests sont en cours pour utiliser mysql 5 et le partitionnement des fichiers pour accélérer les temps d'accès (voir article sur "développez.com", très intéressant ...
Tout ceci n'est qu'un simple avis qui peut vous aider dans votre décision
Bons devs
Marc BENOIT Star'terre 4x4
Firetox wrote:
Bonsoir
SQL sur HF n'est pas la meilleur solution en fait on ne sait pas comment pcsoft fait pour executer les requetes. par contre nous avons des fichiers HF5.5 de 1 Go et nous n'avons pas de problemes mais il est vrai que les index sont aussi volumineux que le fichier. et la ou commence les problemes c'est a la reindexation pour un fichier de ce calibre il faut 2 heures pour le reindexer donc la nuit pas trop de soucis mais si jamais il faut le faire en journée c'est la cata.
donc pour les nouveaux dev nous avons choisi WD7.5 et mysql j'ai des stats sur 5 ans qui font des jointures sur 5 tables dont une contient 200 Millions d'enreg : les stat remontent en 3 secondes !
je pense que votre traitement serait plus rapide en HF qu' en SQL. car HF reste tres rapide mais avec les ordre H. maintenant en SQL sur HF la les performances vont tomber naturellement.
par contre attention, nous n'utilisons pas mySQL avec les ordres H nous faisons tout en requete pure (et SQLManagerX) le resultat est assez probant nos sites sont distant (beziers, paris nantes, avignon et nous nous connectons sur les sites distant sans probleme et on a l'impression d'avoir la base en locale.
bref tout est question de volume, de sites distant ou non, d'ouverture, de modification d'analyse sans refournir un exe etc... voici en fait quelque uns des avantages qui nous ont fait choisir la solution (acces later natif, et SQLManagerX) je ne fais ici aucune pub, mais en 4 ans de dev sur le projet qui doit gerer tous les entrepots en gestion commerciale, et gestion de stock et des magasin, pour l'instant nous n'avons jamais eu de probleme de lenteur. (plutot des problemes de stockage, la base centralisée contient des tables a plus de 300 Millions de lignes) et certain traitement font des jointure sur une dizaines de tables et la base commence a etre tellement grosse qu'on rajoute des disques presque tous les 6 mois.
voila, nous avions tout essayer, HF, SQL sur HF, mysql enfin a peu pres tout
"I.G.LOG" a écrit dans le message de news: 44eb384b$0$874$
J'ai passé tous le fichiers en mode classic (champs terminés par /0). sur la requete que je donne en exemple, je passe de 12 sec à 10. malheureusement toujours pas "admissible" pour les utilisateurs. Mes questions sont donc toujours d'actualité: C/S, WD10, MySQL Encore merci pour vos avis (merci à Gilles notamment)
Bonjour,
Tout à fait d'accord avec tout ce qui a été dit.
Nous avons 4 sites distants, un serveur HF/CS sous linux et une requete, sur
fichiers hyper file - 8 tables concernées, 30 000 à 35 000 enregs,
jointures externes,... - mettait parfois 2 à 3 mn pour arriver
La même requete en ordres H sur fichiers hf classiques environ 20 sec. en
local et parfois 15 à 20 mn en distant
On a tout basculé en MySQL avec ordres SQL purs et durs : temps de réponse
parfois divisé par 80 ...
Dés tests sont en cours pour utiliser mysql 5 et le partitionnement des
fichiers pour accélérer les temps d'accès (voir article sur
"développez.com", très intéressant ...
Tout ceci n'est qu'un simple avis qui peut vous aider dans votre décision
Bons devs
Marc BENOIT
Star'terre 4x4
marc.benoit_sans_spam_@wanadoo.fr
Firetox wrote:
Bonsoir
SQL sur HF n'est pas la meilleur solution
en fait on ne sait pas comment pcsoft fait pour executer les requetes.
par contre nous avons des fichiers HF5.5 de 1 Go et nous n'avons pas de
problemes mais il est vrai que les index sont aussi volumineux que le
fichier. et la ou commence les problemes c'est a la reindexation pour un
fichier de ce calibre il faut 2 heures pour le reindexer donc la nuit pas
trop de soucis mais si jamais il faut le faire en journée c'est la cata.
donc pour les nouveaux dev nous avons choisi WD7.5 et mysql
j'ai des stats sur 5 ans qui font des jointures sur 5 tables dont une
contient 200 Millions d'enreg : les stat remontent en 3 secondes !
je pense que votre traitement serait plus rapide en HF qu' en SQL. car HF
reste tres rapide mais avec les ordre H. maintenant en SQL sur HF la les
performances vont tomber naturellement.
par contre attention, nous n'utilisons pas mySQL avec les ordres H nous
faisons tout en requete pure (et SQLManagerX) le resultat est assez
probant nos sites sont distant (beziers, paris nantes, avignon et nous
nous connectons sur les sites distant sans probleme et on a l'impression
d'avoir la base en locale.
bref tout est question de volume, de sites distant ou non, d'ouverture, de
modification d'analyse sans refournir un exe etc... voici en fait quelque
uns des avantages qui nous ont fait choisir la solution (acces later
natif, et SQLManagerX) je ne fais ici aucune pub, mais en 4 ans de dev sur
le projet qui doit gerer tous les entrepots en gestion commerciale, et
gestion de stock et des magasin, pour l'instant nous n'avons jamais eu de
probleme de lenteur. (plutot des problemes de stockage, la base
centralisée contient des tables a plus de 300 Millions de lignes) et
certain traitement font des jointure sur une dizaines de tables et la base
commence a etre tellement grosse qu'on rajoute des disques presque tous
les 6 mois.
voila, nous avions tout essayer, HF, SQL sur HF, mysql enfin a peu pres
tout
"I.G.LOG" <iglog@free.fr> a écrit dans le message de news:
44eb384b$0$874$ba4acef3@news.orange.fr...
J'ai passé tous le fichiers en mode classic (champs terminés par /0). sur
la
requete que je donne en exemple, je passe de 12 sec à 10. malheureusement
toujours pas "admissible" pour les utilisateurs. Mes questions sont donc
toujours d'actualité: C/S, WD10, MySQL
Encore merci pour vos avis (merci à Gilles notamment)
Tout à fait d'accord avec tout ce qui a été dit. Nous avons 4 sites distants, un serveur HF/CS sous linux et une requete, sur fichiers hyper file - 8 tables concernées, 30 000 à 35 000 enregs, jointures externes,... - mettait parfois 2 à 3 mn pour arriver La même requete en ordres H sur fichiers hf classiques environ 20 sec. en local et parfois 15 à 20 mn en distant
On a tout basculé en MySQL avec ordres SQL purs et durs : temps de réponse parfois divisé par 80 ...
Dés tests sont en cours pour utiliser mysql 5 et le partitionnement des fichiers pour accélérer les temps d'accès (voir article sur "développez.com", très intéressant ...
Tout ceci n'est qu'un simple avis qui peut vous aider dans votre décision
Bons devs
Marc BENOIT Star'terre 4x4
Firetox wrote:
Bonsoir
SQL sur HF n'est pas la meilleur solution en fait on ne sait pas comment pcsoft fait pour executer les requetes. par contre nous avons des fichiers HF5.5 de 1 Go et nous n'avons pas de problemes mais il est vrai que les index sont aussi volumineux que le fichier. et la ou commence les problemes c'est a la reindexation pour un fichier de ce calibre il faut 2 heures pour le reindexer donc la nuit pas trop de soucis mais si jamais il faut le faire en journée c'est la cata.
donc pour les nouveaux dev nous avons choisi WD7.5 et mysql j'ai des stats sur 5 ans qui font des jointures sur 5 tables dont une contient 200 Millions d'enreg : les stat remontent en 3 secondes !
je pense que votre traitement serait plus rapide en HF qu' en SQL. car HF reste tres rapide mais avec les ordre H. maintenant en SQL sur HF la les performances vont tomber naturellement.
par contre attention, nous n'utilisons pas mySQL avec les ordres H nous faisons tout en requete pure (et SQLManagerX) le resultat est assez probant nos sites sont distant (beziers, paris nantes, avignon et nous nous connectons sur les sites distant sans probleme et on a l'impression d'avoir la base en locale.
bref tout est question de volume, de sites distant ou non, d'ouverture, de modification d'analyse sans refournir un exe etc... voici en fait quelque uns des avantages qui nous ont fait choisir la solution (acces later natif, et SQLManagerX) je ne fais ici aucune pub, mais en 4 ans de dev sur le projet qui doit gerer tous les entrepots en gestion commerciale, et gestion de stock et des magasin, pour l'instant nous n'avons jamais eu de probleme de lenteur. (plutot des problemes de stockage, la base centralisée contient des tables a plus de 300 Millions de lignes) et certain traitement font des jointure sur une dizaines de tables et la base commence a etre tellement grosse qu'on rajoute des disques presque tous les 6 mois.
voila, nous avions tout essayer, HF, SQL sur HF, mysql enfin a peu pres tout
"I.G.LOG" a écrit dans le message de news: 44eb384b$0$874$
J'ai passé tous le fichiers en mode classic (champs terminés par /0). sur la requete que je donne en exemple, je passe de 12 sec à 10. malheureusement toujours pas "admissible" pour les utilisateurs. Mes questions sont donc toujours d'actualité: C/S, WD10, MySQL Encore merci pour vos avis (merci à Gilles notamment)
I.G.LOG
Bonjour à tous,
En conclusion, il semblerait que sur les grosses applis (c'est le cas), la raison impose une base plus "appropriée" de type MySQL... J'ai, il y déjà quelques temps, installé un serveur Linux (Fedora Core 3) et Samba prenant en charge la base HF classic. J'espérais améliorer ainsi les performances, notamment car mon client a aujourd'hui une agence qui accède à la base par liaison distante (W2003 TSE). Malheureusement, je ne suis pas spécialiste de Linux et de MySQL ! J'ai installé MySQL 4.10 (je crois) sur le serveur, mais j'ai des problèmes de droit (?!) et je ne peux pas me connecter actuellement ; mais je vais creuser la question puisque c'est la "bonne orientation". Une dernière question: pensez-vous que la version 4.10 de MySQL est la bonne, dois-je envisager de l'upgrader en version 5 ? Encore merci à tous ceux qui se sont penchés sur le problème
PS: me reste pas mal de boulot pour migrer l'appli en SQL pur !!!
Bonjour à tous,
En conclusion, il semblerait que sur les grosses applis (c'est le cas), la
raison impose une base plus "appropriée" de type MySQL...
J'ai, il y déjà quelques temps, installé un serveur Linux (Fedora Core 3) et
Samba prenant en charge la base HF classic. J'espérais améliorer ainsi les
performances, notamment car mon client a aujourd'hui une agence qui accède à
la base par liaison distante (W2003 TSE).
Malheureusement, je ne suis pas spécialiste de Linux et de MySQL ! J'ai
installé MySQL 4.10 (je crois) sur le serveur, mais j'ai des problèmes de
droit (?!) et je ne peux pas me connecter actuellement ; mais je vais
creuser la question puisque c'est la "bonne orientation".
Une dernière question: pensez-vous que la version 4.10 de MySQL est la
bonne, dois-je envisager de l'upgrader en version 5 ?
Encore merci à tous ceux qui se sont penchés sur le problème
PS: me reste pas mal de boulot pour migrer l'appli en SQL pur !!!
En conclusion, il semblerait que sur les grosses applis (c'est le cas), la raison impose une base plus "appropriée" de type MySQL... J'ai, il y déjà quelques temps, installé un serveur Linux (Fedora Core 3) et Samba prenant en charge la base HF classic. J'espérais améliorer ainsi les performances, notamment car mon client a aujourd'hui une agence qui accède à la base par liaison distante (W2003 TSE). Malheureusement, je ne suis pas spécialiste de Linux et de MySQL ! J'ai installé MySQL 4.10 (je crois) sur le serveur, mais j'ai des problèmes de droit (?!) et je ne peux pas me connecter actuellement ; mais je vais creuser la question puisque c'est la "bonne orientation". Une dernière question: pensez-vous que la version 4.10 de MySQL est la bonne, dois-je envisager de l'upgrader en version 5 ? Encore merci à tous ceux qui se sont penchés sur le problème
PS: me reste pas mal de boulot pour migrer l'appli en SQL pur !!!
I.G.LOG
Bonjour, IDDOCUMLG est l'identifiant automatique, IDDOCUM est une clé secondaire. les deux sont des entiers simples (pas de clé composée) La structure des tables est classique: DOCUM -> 1,n <- DOCUMLG (DOCUM corps du document et DOCUMLG les lignes). La requete doit me renvoyer toutes les lignes du document ayant la clé IDDOCUM 3952 (DOCUM est le catalogue articles ayant comme ID 3952, DOCUMLG les articles). Il y a aujourd'hui 78.000 articles dans la table, qui contient 300.000 tuples. En fait, c'est l'execution de la requete qui met environ 12 secondes: effectivement, si je ne place pas d'ORDER, j'arrive à environ 8 secondes (pour les 30 premières lignes). temps toujours trop long selon les utilisateurs ! D'apèrs les posts que j'ai lus, pour avoir de meilleures performances, je devrais m'orienter sur un autre moteur de base de donnée, de type MySQL. C'est la conclusion à laquelle j'arrive; en effet, je travaille sur cette appli depuis 5 ans, dont 3 a essayer de retrouver les perfs de la version 5. Le passage en 7.5 a été CATASTROPHIQUE, les accès par hCreeVue() ont, lors de cette migration, parfois été multipliés par 70 !!! (essais faits sur un hCreeVue() simple sur table unique). Depuis, je transforme tous les hCreeVue en requetes mais sans amélioration des temps de réponse.
En tous cas Merci de t'être penché sur ce problème
Bonjour,
IDDOCUMLG est l'identifiant automatique, IDDOCUM est une clé secondaire. les
deux sont des entiers simples (pas de clé composée)
La structure des tables est classique: DOCUM -> 1,n <- DOCUMLG (DOCUM corps
du document et DOCUMLG les lignes). La requete doit me renvoyer toutes les
lignes du document ayant la clé IDDOCUM 3952 (DOCUM est le catalogue
articles ayant comme ID 3952, DOCUMLG les articles). Il y a aujourd'hui
78.000 articles dans la table, qui contient 300.000 tuples.
En fait, c'est l'execution de la requete qui met environ 12 secondes:
effectivement, si je ne place pas d'ORDER, j'arrive à environ 8 secondes
(pour les 30 premières lignes). temps toujours trop long selon les
utilisateurs !
D'apèrs les posts que j'ai lus, pour avoir de meilleures performances, je
devrais m'orienter sur un autre moteur de base de donnée, de type MySQL.
C'est la conclusion à laquelle j'arrive; en effet, je travaille sur cette
appli depuis 5 ans, dont 3 a essayer de retrouver les perfs de la version 5.
Le passage en 7.5 a été CATASTROPHIQUE, les accès par hCreeVue() ont, lors
de cette migration, parfois été multipliés par 70 !!! (essais faits sur un
hCreeVue() simple sur table unique). Depuis, je transforme tous les hCreeVue
en requetes mais sans amélioration des temps de réponse.
En tous cas Merci de t'être penché sur ce problème
Bonjour, IDDOCUMLG est l'identifiant automatique, IDDOCUM est une clé secondaire. les deux sont des entiers simples (pas de clé composée) La structure des tables est classique: DOCUM -> 1,n <- DOCUMLG (DOCUM corps du document et DOCUMLG les lignes). La requete doit me renvoyer toutes les lignes du document ayant la clé IDDOCUM 3952 (DOCUM est le catalogue articles ayant comme ID 3952, DOCUMLG les articles). Il y a aujourd'hui 78.000 articles dans la table, qui contient 300.000 tuples. En fait, c'est l'execution de la requete qui met environ 12 secondes: effectivement, si je ne place pas d'ORDER, j'arrive à environ 8 secondes (pour les 30 premières lignes). temps toujours trop long selon les utilisateurs ! D'apèrs les posts que j'ai lus, pour avoir de meilleures performances, je devrais m'orienter sur un autre moteur de base de donnée, de type MySQL. C'est la conclusion à laquelle j'arrive; en effet, je travaille sur cette appli depuis 5 ans, dont 3 a essayer de retrouver les perfs de la version 5. Le passage en 7.5 a été CATASTROPHIQUE, les accès par hCreeVue() ont, lors de cette migration, parfois été multipliés par 70 !!! (essais faits sur un hCreeVue() simple sur table unique). Depuis, je transforme tous les hCreeVue en requetes mais sans amélioration des temps de réponse.
En tous cas Merci de t'être penché sur ce problème
Firetox
Bonjour,
notre version de production est pour l'instant la version 4.1.15 nous avons commence en 3.23
les mise a jour n'ont pas pose de problemes. nous avons aussi pris en compte certaines nouveautes comme les osus select etc ... pour la version 5 nous attendons un peu car lorque nous faisons une MAJ il faut mettre a jour 6 gros serveurs avec des bases volumineuses donc nous faisons les migrations la nuits, mais on ne peut pas toutes les faire en meme temps. mais tant que nous ne sommes pas bloques par la version il n'y a pas de raison de changer nous sommes passe a la 4.1 pour les sous select mais pur l'intant la 5 ne nous apporterait rien de bien essentiel. mais notre acces est pres donc quand le serveur passera en 5 il n'y aura pas de livraison d'exe a faire
bon dev @+
Firetox
"I.G.LOG" a écrit dans le message de news: 44ebebf2$0$888$
Bonjour à tous,
En conclusion, il semblerait que sur les grosses applis (c'est le cas), la raison impose une base plus "appropriée" de type MySQL... J'ai, il y déjà quelques temps, installé un serveur Linux (Fedora Core 3) et Samba prenant en charge la base HF classic. J'espérais améliorer ainsi les performances, notamment car mon client a aujourd'hui une agence qui accède à la base par liaison distante (W2003 TSE). Malheureusement, je ne suis pas spécialiste de Linux et de MySQL ! J'ai installé MySQL 4.10 (je crois) sur le serveur, mais j'ai des problèmes de droit (?!) et je ne peux pas me connecter actuellement ; mais je vais creuser la question puisque c'est la "bonne orientation". Une dernière question: pensez-vous que la version 4.10 de MySQL est la bonne, dois-je envisager de l'upgrader en version 5 ? Encore merci à tous ceux qui se sont penchés sur le problème
PS: me reste pas mal de boulot pour migrer l'appli en SQL pur !!!
Bonjour,
notre version de production est pour l'instant la version 4.1.15
nous avons commence en 3.23
les mise a jour n'ont pas pose de problemes. nous avons aussi pris en compte
certaines nouveautes comme les osus select etc ...
pour la version 5 nous attendons un peu car lorque nous faisons une MAJ il
faut mettre a jour 6 gros serveurs avec des bases volumineuses donc nous
faisons les migrations la nuits, mais on ne peut pas toutes les faire en
meme temps. mais tant que nous ne sommes pas bloques par la version il n'y a
pas de raison de changer nous sommes passe a la 4.1 pour les sous select
mais pur l'intant la 5 ne nous apporterait rien de bien essentiel. mais
notre acces est pres donc quand le serveur passera en 5 il n'y aura pas de
livraison d'exe a faire
bon dev
@+
Firetox
"I.G.LOG" <iglog@free.fr> a écrit dans le message de news:
44ebebf2$0$888$ba4acef3@news.orange.fr...
Bonjour à tous,
En conclusion, il semblerait que sur les grosses applis (c'est le cas), la
raison impose une base plus "appropriée" de type MySQL...
J'ai, il y déjà quelques temps, installé un serveur Linux (Fedora Core 3)
et
Samba prenant en charge la base HF classic. J'espérais améliorer ainsi les
performances, notamment car mon client a aujourd'hui une agence qui accède
à
la base par liaison distante (W2003 TSE).
Malheureusement, je ne suis pas spécialiste de Linux et de MySQL ! J'ai
installé MySQL 4.10 (je crois) sur le serveur, mais j'ai des problèmes de
droit (?!) et je ne peux pas me connecter actuellement ; mais je vais
creuser la question puisque c'est la "bonne orientation".
Une dernière question: pensez-vous que la version 4.10 de MySQL est la
bonne, dois-je envisager de l'upgrader en version 5 ?
Encore merci à tous ceux qui se sont penchés sur le problème
PS: me reste pas mal de boulot pour migrer l'appli en SQL pur !!!
notre version de production est pour l'instant la version 4.1.15 nous avons commence en 3.23
les mise a jour n'ont pas pose de problemes. nous avons aussi pris en compte certaines nouveautes comme les osus select etc ... pour la version 5 nous attendons un peu car lorque nous faisons une MAJ il faut mettre a jour 6 gros serveurs avec des bases volumineuses donc nous faisons les migrations la nuits, mais on ne peut pas toutes les faire en meme temps. mais tant que nous ne sommes pas bloques par la version il n'y a pas de raison de changer nous sommes passe a la 4.1 pour les sous select mais pur l'intant la 5 ne nous apporterait rien de bien essentiel. mais notre acces est pres donc quand le serveur passera en 5 il n'y aura pas de livraison d'exe a faire
bon dev @+
Firetox
"I.G.LOG" a écrit dans le message de news: 44ebebf2$0$888$
Bonjour à tous,
En conclusion, il semblerait que sur les grosses applis (c'est le cas), la raison impose une base plus "appropriée" de type MySQL... J'ai, il y déjà quelques temps, installé un serveur Linux (Fedora Core 3) et Samba prenant en charge la base HF classic. J'espérais améliorer ainsi les performances, notamment car mon client a aujourd'hui une agence qui accède à la base par liaison distante (W2003 TSE). Malheureusement, je ne suis pas spécialiste de Linux et de MySQL ! J'ai installé MySQL 4.10 (je crois) sur le serveur, mais j'ai des problèmes de droit (?!) et je ne peux pas me connecter actuellement ; mais je vais creuser la question puisque c'est la "bonne orientation". Une dernière question: pensez-vous que la version 4.10 de MySQL est la bonne, dois-je envisager de l'upgrader en version 5 ? Encore merci à tous ceux qui se sont penchés sur le problème
PS: me reste pas mal de boulot pour migrer l'appli en SQL pur !!!
jacques trepp
Bonjour,
pour notre part, nous avons opté depuis 2 ans pour l'utilisation des bases mysql (4.1.10), et postgresql (8.1.3), sur des serveurs sous linux redhat es 4. l'utilisation des classes alter natives nous permet d'utiliser des ordres "à la hf", ou plus simplement des requètes en langage sql. l'intéret de ces dernières étant bien sur de pouvoir les tester hors du contexte windev. certaines de nos tables mysql dépassent les 3 millions de lignes, et les résultats sont toujours aussi rapides.
Pour ma part, et depuis la version 2 de windev, les bases hf ont toujours été un cauchemar.
je ne me suis pas aussi bien senti que depuis le changement de bases.
cordialement
-- Jacques Trepp Albygest - 81160 - St Juery jacques-pas de (enlever '-pas de spam' pour me joindre) http://www.albygest.com
Bonjour,
pour notre part, nous avons opté depuis 2 ans pour l'utilisation des
bases mysql (4.1.10), et postgresql (8.1.3), sur des serveurs sous linux
redhat es 4.
l'utilisation des classes alter natives nous permet d'utiliser des
ordres "à la hf", ou plus simplement des requètes en langage sql.
l'intéret de ces dernières étant bien sur de pouvoir les tester hors du
contexte windev.
certaines de nos tables mysql dépassent les 3 millions de lignes, et les
résultats sont toujours aussi rapides.
Pour ma part, et depuis la version 2 de windev, les bases hf ont
toujours été un cauchemar.
je ne me suis pas aussi bien senti que depuis le changement de bases.
cordialement
--
Jacques Trepp
Albygest - 81160 - St Juery
jacques-pas de spam.trepp@free.fr
(enlever '-pas de spam' pour me joindre)
http://www.albygest.com
pour notre part, nous avons opté depuis 2 ans pour l'utilisation des bases mysql (4.1.10), et postgresql (8.1.3), sur des serveurs sous linux redhat es 4. l'utilisation des classes alter natives nous permet d'utiliser des ordres "à la hf", ou plus simplement des requètes en langage sql. l'intéret de ces dernières étant bien sur de pouvoir les tester hors du contexte windev. certaines de nos tables mysql dépassent les 3 millions de lignes, et les résultats sont toujours aussi rapides.
Pour ma part, et depuis la version 2 de windev, les bases hf ont toujours été un cauchemar.
je ne me suis pas aussi bien senti que depuis le changement de bases.
cordialement
-- Jacques Trepp Albygest - 81160 - St Juery jacques-pas de (enlever '-pas de spam' pour me joindre) http://www.albygest.com
Vbig
I.G.LOG a utilisé son clavier pour écrire :
Bonjour, IDDOCUMLG est l'identifiant automatique, IDDOCUM est une clé secondaire. les deux sont des entiers simples (pas de clé composée) La structure des tables est classique: DOCUM -> 1,n <- DOCUMLG (DOCUM corps du document et DOCUMLG les lignes). La requete doit me renvoyer toutes les lignes du document ayant la clé IDDOCUM 3952 (DOCUM est le catalogue articles ayant comme ID 3952, DOCUMLG les articles). Il y a aujourd'hui 78.000 articles dans la table, qui contient 300.000 tuples. En fait, c'est l'execution de la requete qui met environ 12 secondes: effectivement, si je ne place pas d'ORDER, j'arrive à environ 8 secondes (pour les 30 premières lignes). temps toujours trop long selon les utilisateurs ! D'apèrs les posts que j'ai lus, pour avoir de meilleures performances, je devrais m'orienter sur un autre moteur de base de donnée, de type MySQL. C'est la conclusion à laquelle j'arrive; en effet, je travaille sur cette appli depuis 5 ans, dont 3 a essayer de retrouver les perfs de la version 5. Le passage en 7.5 a été CATASTROPHIQUE, les accès par hCreeVue() ont, lors de cette migration, parfois été multipliés par 70 !!! (essais faits sur un hCreeVue() simple sur table unique). Depuis, je transforme tous les hCreeVue en requetes mais sans amélioration des temps de réponse.
En tous cas Merci de t'être penché sur ce problème
Nous avons également migrer de grosses application 5.5 => 8 Nous n'avons pas eut de problème de perte de performance sur les HCreevue. (sauf sur les jointures de vues) A noter toutefois une astuces (que nous utilisions déjà presque toujours en 5.5), il ne faut pas renseigner de valeur de tris lors de la création Trier la vue après le hcréevue fait gagner un temps considérable.
Est ce possible également avec les requetes, je ne sais pas...
I.G.LOG a utilisé son clavier pour écrire :
Bonjour,
IDDOCUMLG est l'identifiant automatique, IDDOCUM est une clé secondaire. les
deux sont des entiers simples (pas de clé composée)
La structure des tables est classique: DOCUM -> 1,n <- DOCUMLG (DOCUM corps
du document et DOCUMLG les lignes). La requete doit me renvoyer toutes les
lignes du document ayant la clé IDDOCUM 3952 (DOCUM est le catalogue
articles ayant comme ID 3952, DOCUMLG les articles). Il y a aujourd'hui
78.000 articles dans la table, qui contient 300.000 tuples.
En fait, c'est l'execution de la requete qui met environ 12 secondes:
effectivement, si je ne place pas d'ORDER, j'arrive à environ 8 secondes
(pour les 30 premières lignes). temps toujours trop long selon les
utilisateurs !
D'apèrs les posts que j'ai lus, pour avoir de meilleures performances, je
devrais m'orienter sur un autre moteur de base de donnée, de type MySQL.
C'est la conclusion à laquelle j'arrive; en effet, je travaille sur cette
appli depuis 5 ans, dont 3 a essayer de retrouver les perfs de la version 5.
Le passage en 7.5 a été CATASTROPHIQUE, les accès par hCreeVue() ont, lors
de cette migration, parfois été multipliés par 70 !!! (essais faits sur un
hCreeVue() simple sur table unique). Depuis, je transforme tous les hCreeVue
en requetes mais sans amélioration des temps de réponse.
En tous cas Merci de t'être penché sur ce problème
Nous avons également migrer de grosses application 5.5 => 8
Nous n'avons pas eut de problème de perte de performance sur les
HCreevue. (sauf sur les jointures de vues)
A noter toutefois une astuces (que nous utilisions déjà presque
toujours en 5.5), il ne faut pas renseigner de valeur de tris lors de
la création
Trier la vue après le hcréevue fait gagner un temps considérable.
Est ce possible également avec les requetes, je ne sais pas...
Bonjour, IDDOCUMLG est l'identifiant automatique, IDDOCUM est une clé secondaire. les deux sont des entiers simples (pas de clé composée) La structure des tables est classique: DOCUM -> 1,n <- DOCUMLG (DOCUM corps du document et DOCUMLG les lignes). La requete doit me renvoyer toutes les lignes du document ayant la clé IDDOCUM 3952 (DOCUM est le catalogue articles ayant comme ID 3952, DOCUMLG les articles). Il y a aujourd'hui 78.000 articles dans la table, qui contient 300.000 tuples. En fait, c'est l'execution de la requete qui met environ 12 secondes: effectivement, si je ne place pas d'ORDER, j'arrive à environ 8 secondes (pour les 30 premières lignes). temps toujours trop long selon les utilisateurs ! D'apèrs les posts que j'ai lus, pour avoir de meilleures performances, je devrais m'orienter sur un autre moteur de base de donnée, de type MySQL. C'est la conclusion à laquelle j'arrive; en effet, je travaille sur cette appli depuis 5 ans, dont 3 a essayer de retrouver les perfs de la version 5. Le passage en 7.5 a été CATASTROPHIQUE, les accès par hCreeVue() ont, lors de cette migration, parfois été multipliés par 70 !!! (essais faits sur un hCreeVue() simple sur table unique). Depuis, je transforme tous les hCreeVue en requetes mais sans amélioration des temps de réponse.
En tous cas Merci de t'être penché sur ce problème
Nous avons également migrer de grosses application 5.5 => 8 Nous n'avons pas eut de problème de perte de performance sur les HCreevue. (sauf sur les jointures de vues) A noter toutefois une astuces (que nous utilisions déjà presque toujours en 5.5), il ne faut pas renseigner de valeur de tris lors de la création Trier la vue après le hcréevue fait gagner un temps considérable.
Est ce possible également avec les requetes, je ne sais pas...
mat
Vbig wrote: ...
Nous avons également migrer de grosses application 5.5 => 8 Nous n'avons pas eut de problème de perte de performance sur les HCreevue. (sauf sur les jointures de vues) A noter toutefois une astuces (que nous utilisions déjà presque toujours en 5.5), il ne faut pas renseigner de valeur de tris lors de la création Trier la vue après le hcréevue fait gagner un temps considérable.
Est ce possible également avec les requetes, je ne sais pas...
... malheureusement pas ...
Vbig wrote:
...
Nous avons également migrer de grosses application 5.5 => 8
Nous n'avons pas eut de problème de perte de performance sur les
HCreevue. (sauf sur les jointures de vues)
A noter toutefois une astuces (que nous utilisions déjà presque toujours
en 5.5), il ne faut pas renseigner de valeur de tris lors de la création
Trier la vue après le hcréevue fait gagner un temps considérable.
Est ce possible également avec les requetes, je ne sais pas...
Nous avons également migrer de grosses application 5.5 => 8 Nous n'avons pas eut de problème de perte de performance sur les HCreevue. (sauf sur les jointures de vues) A noter toutefois une astuces (que nous utilisions déjà presque toujours en 5.5), il ne faut pas renseigner de valeur de tris lors de la création Trier la vue après le hcréevue fait gagner un temps considérable.
Est ce possible également avec les requetes, je ne sais pas...
