> [CUT]
Le peu de réponses reçues à nos questions signifierait que ces
sont normales ? Pourquoi est on si lent alors qu'on est très loin des
volumes maximums annoncés par PcSoft dans ses publicités (mensongères?),
soit +300 milliards de records ?
> [CUT]
Le peu de réponses reçues à nos questions signifierait que ces
sont normales ? Pourquoi est on si lent alors qu'on est très loin des
volumes maximums annoncés par PcSoft dans ses publicités (mensongères?),
soit +300 milliards de records ?
> [CUT]
Le peu de réponses reçues à nos questions signifierait que ces
sont normales ? Pourquoi est on si lent alors qu'on est très loin des
volumes maximums annoncés par PcSoft dans ses publicités (mensongères?),
soit +300 milliards de records ?
Notre application effectue des acquisitions de données (de qq centaines à
plusieurs milliers par minute).
Certaines versions devant être exploitées sur des ordinateurs portables,
des sites externes, il nous semble préférable d'utiliser HF7 dans ce
contexte, au lieu d'être obligés de demander à nos client d'installer sur
serveur MySQL pour un simple application monoposte.
Un autre problème que nous rencontrons avec HF7 est que les performances
insertions diminuent à mesure que la taille de la BD augmente. Il arrive
nous devions insérer 3000 ou 4000 enregistrements en une minute, mais HF7
tient pas la cadence. La solution de contournement que nous avons est
d'écrire nos données dans un fichier texte, avec un thread secondaire qui
relit le fichier et effectue les insertions au rythme supporté par HF7.
terrible sur le principe, mais ça fonctionne.
Le peu de réponses reçues à nos questions signifierait que ces
sont normales ? Pourquoi est on si lent alors qu'on est très loin des
volumes maximums annoncés par PcSoft dans ses publicités (mensongères?),
soit +300 milliards de records ?
"Roumegou" a écrit dans le message de
news:
> Moi ce que je ne comprends pas, c'est le pourquoi de sortir votre appli
> pour mySQL et HF7 ???
>
> Je veux bien comprendre le besoin de s'ouvrir à plusieurs SGBD standard
> comme Oracle, sqlserver, mysql, PostgreSQL car ce peut être un élément
> de décision pour le client.
>
> Mais HF ? Je doute que cela soit un argument commercial du fait de la
> confidentialité de cette base.
> Donc pourquoi ne pas proposer que mysql ?
> Ou alors, on choisit HF car on doit avoir des installations monopostes
> et pour des petites quantités. Il est peut être alors plus facile
> d'installer des fichiers HF et les pb de perfs sont inexistants.
> Mais quand on parle de 2000000 d'enreg, la question ne devrait mème pas
> se poser, surtout si notre code est dès le depart orienté SQL.
>
> ... a exposé le 10/06/2004 :
> >> La raison de la lenteur de la première lecture est assez simple et a
été
> >> mentionné à plusieures reprises sur ce forum: Windev ecrit dans un
> >> fichier et lit en mémoire chaque ligne du résultat, tandis que
> >> produits ne lisent que les lignes affichées. Les lectures suivantes
sont
> >> trouvé dans le cache et donc plus rapides.
> >
> > Une requête de type "select count(*) from table" renvoie 1 valeur et
un
> > paquet de lignes !
> >
> > 67 secondes pour renvoyer le nombre total de lignes d'une table, sans
aucune
> > clause WHERE est inacceptable (en effet dans ce cas il est inutile de
> > parcourir les index). En plus ce résultat est obtenu EN LOCAL (P4
3.2Ghz),
> > alors que le 0.08s en MySql est obtenu en accédant à une autre machine
du
> > RÉSEAU (P3 500Mhz) qui roule MySQL sous Linux.
> >
> > Ce qui nous fait peur, c'est que les 427000 enregistrements sont un
> > échantillon des données que nous devons traiter dans la verison finale
(qui
> > va contenir environ 2000000 d'enregistrements). Nous espérons que les
temps
> > ne seront pas proportionnels :-(
> >
> > Sommes-nous les seuls à utiliser SQL/HF7 avec des tables conséquentes
(mais
> > pas énormes, nous n'en sommes pas à +10 milliards d'enregistrements
comme
> > sur un autre de nos projets en Oracle) ? En passant, voilà de quoi
> > réflechir pcsoft sur les performances de HF7 (Oracle renvoie un count
+10
> > milliards en 0.14s) :
> >
> > ------------------------------------------------------------------
> > select count(*) from mesures
> >
> > Result 1 field(s), 1 record(s), time 0.14 sec
> >
> > count(*)
> > ---------------------
> > 10.006.507.317
> >
> > ------------------------------------------------------------------
> >
> > En recherchant une solution sur les archives je vois que certains
> > WDprogrammeurs affirment que le SQL/HF7 est plus lent que les ordres
> > hyperfile classiques (hLit*). Est-ce réel ? Ce serait-il une
à
> > nos problèmes de perf ?
> >
> > Merci
> >
> > ...
>
> --
> Eric Roumégou
> http://cerbermail.com/?TSoulBerPA
> (cliquez sur le lien ci-dessus pour me contacter en privé)
>
Notre application effectue des acquisitions de données (de qq centaines à
plusieurs milliers par minute).
Certaines versions devant être exploitées sur des ordinateurs portables,
des sites externes, il nous semble préférable d'utiliser HF7 dans ce
contexte, au lieu d'être obligés de demander à nos client d'installer sur
serveur MySQL pour un simple application monoposte.
Un autre problème que nous rencontrons avec HF7 est que les performances
insertions diminuent à mesure que la taille de la BD augmente. Il arrive
nous devions insérer 3000 ou 4000 enregistrements en une minute, mais HF7
tient pas la cadence. La solution de contournement que nous avons est
d'écrire nos données dans un fichier texte, avec un thread secondaire qui
relit le fichier et effectue les insertions au rythme supporté par HF7.
terrible sur le principe, mais ça fonctionne.
Le peu de réponses reçues à nos questions signifierait que ces
sont normales ? Pourquoi est on si lent alors qu'on est très loin des
volumes maximums annoncés par PcSoft dans ses publicités (mensongères?),
soit +300 milliards de records ?
"Roumegou" <Utilisezlelien@fin.msg> a écrit dans le message de
news:mn.51f27d4614839a88.11485@fin.msg...
> Moi ce que je ne comprends pas, c'est le pourquoi de sortir votre appli
> pour mySQL et HF7 ???
>
> Je veux bien comprendre le besoin de s'ouvrir à plusieurs SGBD standard
> comme Oracle, sqlserver, mysql, PostgreSQL car ce peut être un élément
> de décision pour le client.
>
> Mais HF ? Je doute que cela soit un argument commercial du fait de la
> confidentialité de cette base.
> Donc pourquoi ne pas proposer que mysql ?
> Ou alors, on choisit HF car on doit avoir des installations monopostes
> et pour des petites quantités. Il est peut être alors plus facile
> d'installer des fichiers HF et les pb de perfs sont inexistants.
> Mais quand on parle de 2000000 d'enreg, la question ne devrait mème pas
> se poser, surtout si notre code est dès le depart orienté SQL.
>
> ... a exposé le 10/06/2004 :
> >> La raison de la lenteur de la première lecture est assez simple et a
été
> >> mentionné à plusieures reprises sur ce forum: Windev ecrit dans un
> >> fichier et lit en mémoire chaque ligne du résultat, tandis que
> >> produits ne lisent que les lignes affichées. Les lectures suivantes
sont
> >> trouvé dans le cache et donc plus rapides.
> >
> > Une requête de type "select count(*) from table" renvoie 1 valeur et
un
> > paquet de lignes !
> >
> > 67 secondes pour renvoyer le nombre total de lignes d'une table, sans
aucune
> > clause WHERE est inacceptable (en effet dans ce cas il est inutile de
> > parcourir les index). En plus ce résultat est obtenu EN LOCAL (P4
3.2Ghz),
> > alors que le 0.08s en MySql est obtenu en accédant à une autre machine
du
> > RÉSEAU (P3 500Mhz) qui roule MySQL sous Linux.
> >
> > Ce qui nous fait peur, c'est que les 427000 enregistrements sont un
> > échantillon des données que nous devons traiter dans la verison finale
(qui
> > va contenir environ 2000000 d'enregistrements). Nous espérons que les
temps
> > ne seront pas proportionnels :-(
> >
> > Sommes-nous les seuls à utiliser SQL/HF7 avec des tables conséquentes
(mais
> > pas énormes, nous n'en sommes pas à +10 milliards d'enregistrements
comme
> > sur un autre de nos projets en Oracle) ? En passant, voilà de quoi
> > réflechir pcsoft sur les performances de HF7 (Oracle renvoie un count
+10
> > milliards en 0.14s) :
> >
> > ------------------------------------------------------------------
> > select count(*) from mesures
> >
> > Result 1 field(s), 1 record(s), time 0.14 sec
> >
> > count(*)
> > ---------------------
> > 10.006.507.317
> >
> > ------------------------------------------------------------------
> >
> > En recherchant une solution sur les archives je vois que certains
> > WDprogrammeurs affirment que le SQL/HF7 est plus lent que les ordres
> > hyperfile classiques (hLit*). Est-ce réel ? Ce serait-il une
à
> > nos problèmes de perf ?
> >
> > Merci
> >
> > ...
>
> --
> Eric Roumégou
> http://cerbermail.com/?TSoulBerPA
> (cliquez sur le lien ci-dessus pour me contacter en privé)
>
Notre application effectue des acquisitions de données (de qq centaines à
plusieurs milliers par minute).
Certaines versions devant être exploitées sur des ordinateurs portables,
des sites externes, il nous semble préférable d'utiliser HF7 dans ce
contexte, au lieu d'être obligés de demander à nos client d'installer sur
serveur MySQL pour un simple application monoposte.
Un autre problème que nous rencontrons avec HF7 est que les performances
insertions diminuent à mesure que la taille de la BD augmente. Il arrive
nous devions insérer 3000 ou 4000 enregistrements en une minute, mais HF7
tient pas la cadence. La solution de contournement que nous avons est
d'écrire nos données dans un fichier texte, avec un thread secondaire qui
relit le fichier et effectue les insertions au rythme supporté par HF7.
terrible sur le principe, mais ça fonctionne.
Le peu de réponses reçues à nos questions signifierait que ces
sont normales ? Pourquoi est on si lent alors qu'on est très loin des
volumes maximums annoncés par PcSoft dans ses publicités (mensongères?),
soit +300 milliards de records ?
"Roumegou" a écrit dans le message de
news:
> Moi ce que je ne comprends pas, c'est le pourquoi de sortir votre appli
> pour mySQL et HF7 ???
>
> Je veux bien comprendre le besoin de s'ouvrir à plusieurs SGBD standard
> comme Oracle, sqlserver, mysql, PostgreSQL car ce peut être un élément
> de décision pour le client.
>
> Mais HF ? Je doute que cela soit un argument commercial du fait de la
> confidentialité de cette base.
> Donc pourquoi ne pas proposer que mysql ?
> Ou alors, on choisit HF car on doit avoir des installations monopostes
> et pour des petites quantités. Il est peut être alors plus facile
> d'installer des fichiers HF et les pb de perfs sont inexistants.
> Mais quand on parle de 2000000 d'enreg, la question ne devrait mème pas
> se poser, surtout si notre code est dès le depart orienté SQL.
>
> ... a exposé le 10/06/2004 :
> >> La raison de la lenteur de la première lecture est assez simple et a
été
> >> mentionné à plusieures reprises sur ce forum: Windev ecrit dans un
> >> fichier et lit en mémoire chaque ligne du résultat, tandis que
> >> produits ne lisent que les lignes affichées. Les lectures suivantes
sont
> >> trouvé dans le cache et donc plus rapides.
> >
> > Une requête de type "select count(*) from table" renvoie 1 valeur et
un
> > paquet de lignes !
> >
> > 67 secondes pour renvoyer le nombre total de lignes d'une table, sans
aucune
> > clause WHERE est inacceptable (en effet dans ce cas il est inutile de
> > parcourir les index). En plus ce résultat est obtenu EN LOCAL (P4
3.2Ghz),
> > alors que le 0.08s en MySql est obtenu en accédant à une autre machine
du
> > RÉSEAU (P3 500Mhz) qui roule MySQL sous Linux.
> >
> > Ce qui nous fait peur, c'est que les 427000 enregistrements sont un
> > échantillon des données que nous devons traiter dans la verison finale
(qui
> > va contenir environ 2000000 d'enregistrements). Nous espérons que les
temps
> > ne seront pas proportionnels :-(
> >
> > Sommes-nous les seuls à utiliser SQL/HF7 avec des tables conséquentes
(mais
> > pas énormes, nous n'en sommes pas à +10 milliards d'enregistrements
comme
> > sur un autre de nos projets en Oracle) ? En passant, voilà de quoi
> > réflechir pcsoft sur les performances de HF7 (Oracle renvoie un count
+10
> > milliards en 0.14s) :
> >
> > ------------------------------------------------------------------
> > select count(*) from mesures
> >
> > Result 1 field(s), 1 record(s), time 0.14 sec
> >
> > count(*)
> > ---------------------
> > 10.006.507.317
> >
> > ------------------------------------------------------------------
> >
> > En recherchant une solution sur les archives je vois que certains
> > WDprogrammeurs affirment que le SQL/HF7 est plus lent que les ordres
> > hyperfile classiques (hLit*). Est-ce réel ? Ce serait-il une
à
> > nos problèmes de perf ?
> >
> > Merci
> >
> > ...
>
> --
> Eric Roumégou
> http://cerbermail.com/?TSoulBerPA
> (cliquez sur le lien ci-dessus pour me contacter en privé)
>
Bonjour,
Je pense que la vitesse d'insertion est aussi sujette au nombre de
clés et de leur taille dans le fichier concerné.
Avez-vous beaucoup de clés ou de clés ayant les mêmes valeurs dans de
nombreux enregistrements ?
Cordialement
Jean
"..." a écrit dans le message de
news:Notre application effectue des acquisitions de données (de qq
centaines à plusieurs milliers par minute).
Certaines versions devant être exploitées sur des ordinateurs
portables, sur des sites externes, il nous semble préférable
d'utiliser HF7 dans ce contexte, au lieu d'être obligés de demander
à nos client d'installer sur serveur MySQL pour un simple
application monoposte.
Un autre problème que nous rencontrons avec HF7 est que les
performances des insertions diminuent à mesure que la taille de la
BD augmente. Il arrive que nous devions insérer 3000 ou 4000
enregistrements en une minute, mais HF7 ne tient pas la cadence. La
solution de contournement que nous avons est d'écrire nos données
dans un fichier texte, avec un thread secondaire qui relit le
fichier et effectue les insertions au rythme supporté par HF7. Pas
terrible sur le principe, mais ça fonctionne.
Le peu de réponses reçues à nos questions signifierait que ces
performances sont normales ? Pourquoi est on si lent alors qu'on est
très loin des volumes maximums annoncés par PcSoft dans ses
publicités (mensongères?), soit +300 milliards de records ?
"Roumegou" a écrit dans le message de
news:Moi ce que je ne comprends pas, c'est le pourquoi de sortir votre
appli pour mySQL et HF7 ???
Je veux bien comprendre le besoin de s'ouvrir à plusieurs SGBD
standard comme Oracle, sqlserver, mysql, PostgreSQL car ce peut
être un élément de décision pour le client.
Mais HF ? Je doute que cela soit un argument commercial du fait de
la confidentialité de cette base.
Donc pourquoi ne pas proposer que mysql ?
Ou alors, on choisit HF car on doit avoir des installations
monopostes et pour des petites quantités. Il est peut être alors
plus facile d'installer des fichiers HF et les pb de perfs sont
inexistants.
Mais quand on parle de 2000000 d'enreg, la question ne devrait mème
pas se poser, surtout si notre code est dès le depart orienté SQL.
... a exposé le 10/06/2004 :La raison de la lenteur de la première lecture est assez simple
et a été mentionné à plusieures reprises sur ce forum: Windev
ecrit dans un fichier et lit en mémoire chaque ligne du résultat,
tandis que d'autres produits ne lisent que les lignes affichées.
Les lectures suivantes sont trouvé dans le cache et donc plus
rapides.
Une requête de type "select count(*) from table" renvoie 1 valeur
et non un paquet de lignes !
67 secondes pour renvoyer le nombre total de lignes d'une table,
sans aucune clause WHERE est inacceptable (en effet dans ce cas il
est inutile de parcourir les index). En plus ce résultat est
obtenu EN LOCAL (P4 3.2Ghz), alors que le 0.08s en MySql est
obtenu en accédant à une autre machine du RÉSEAU (P3 500Mhz) qui
roule MySQL sous Linux.
Ce qui nous fait peur, c'est que les 427000 enregistrements sont un
échantillon des données que nous devons traiter dans la verison
finale (qui va contenir environ 2000000 d'enregistrements). Nous
espérons que les temps ne seront pas proportionnels :-(
Sommes-nous les seuls à utiliser SQL/HF7 avec des tables
conséquentes (mais pas énormes, nous n'en sommes pas à +10
milliards d'enregistrements comme sur un autre de nos projets en
Oracle) ? En passant, voilà de quoi faire réflechir pcsoft sur les
performances de HF7 (Oracle renvoie un count de +10 milliards en
0.14s) :
------------------------------------------------------------------
select count(*) from mesures
Result 1 field(s), 1 record(s), time 0.14 sec
count(*)
---------------------
10.006.507.317
------------------------------------------------------------------
En recherchant une solution sur les archives je vois que certains
WDprogrammeurs affirment que le SQL/HF7 est plus lent que les
ordres hyperfile classiques (hLit*). Est-ce réel ? Ce serait-il
une explication à nos problèmes de perf ?
Merci
...
--
Eric Roumégou
http://cerbermail.com/?TSoulBerPA
(cliquez sur le lien ci-dessus pour me contacter en privé)
Bonjour,
Je pense que la vitesse d'insertion est aussi sujette au nombre de
clés et de leur taille dans le fichier concerné.
Avez-vous beaucoup de clés ou de clés ayant les mêmes valeurs dans de
nombreux enregistrements ?
Cordialement
Jean
"..." <...@...> a écrit dans le message de
news:c568a182f13ffb48ae85c7d8c405d1a6@news.teranews.com...
Notre application effectue des acquisitions de données (de qq
centaines à plusieurs milliers par minute).
Certaines versions devant être exploitées sur des ordinateurs
portables, sur des sites externes, il nous semble préférable
d'utiliser HF7 dans ce contexte, au lieu d'être obligés de demander
à nos client d'installer sur serveur MySQL pour un simple
application monoposte.
Un autre problème que nous rencontrons avec HF7 est que les
performances des insertions diminuent à mesure que la taille de la
BD augmente. Il arrive que nous devions insérer 3000 ou 4000
enregistrements en une minute, mais HF7 ne tient pas la cadence. La
solution de contournement que nous avons est d'écrire nos données
dans un fichier texte, avec un thread secondaire qui relit le
fichier et effectue les insertions au rythme supporté par HF7. Pas
terrible sur le principe, mais ça fonctionne.
Le peu de réponses reçues à nos questions signifierait que ces
performances sont normales ? Pourquoi est on si lent alors qu'on est
très loin des volumes maximums annoncés par PcSoft dans ses
publicités (mensongères?), soit +300 milliards de records ?
"Roumegou" <Utilisezlelien@fin.msg> a écrit dans le message de
news:mn.51f27d4614839a88.11485@fin.msg...
Moi ce que je ne comprends pas, c'est le pourquoi de sortir votre
appli pour mySQL et HF7 ???
Je veux bien comprendre le besoin de s'ouvrir à plusieurs SGBD
standard comme Oracle, sqlserver, mysql, PostgreSQL car ce peut
être un élément de décision pour le client.
Mais HF ? Je doute que cela soit un argument commercial du fait de
la confidentialité de cette base.
Donc pourquoi ne pas proposer que mysql ?
Ou alors, on choisit HF car on doit avoir des installations
monopostes et pour des petites quantités. Il est peut être alors
plus facile d'installer des fichiers HF et les pb de perfs sont
inexistants.
Mais quand on parle de 2000000 d'enreg, la question ne devrait mème
pas se poser, surtout si notre code est dès le depart orienté SQL.
... a exposé le 10/06/2004 :
La raison de la lenteur de la première lecture est assez simple
et a été mentionné à plusieures reprises sur ce forum: Windev
ecrit dans un fichier et lit en mémoire chaque ligne du résultat,
tandis que d'autres produits ne lisent que les lignes affichées.
Les lectures suivantes sont trouvé dans le cache et donc plus
rapides.
Une requête de type "select count(*) from table" renvoie 1 valeur
et non un paquet de lignes !
67 secondes pour renvoyer le nombre total de lignes d'une table,
sans aucune clause WHERE est inacceptable (en effet dans ce cas il
est inutile de parcourir les index). En plus ce résultat est
obtenu EN LOCAL (P4 3.2Ghz), alors que le 0.08s en MySql est
obtenu en accédant à une autre machine du RÉSEAU (P3 500Mhz) qui
roule MySQL sous Linux.
Ce qui nous fait peur, c'est que les 427000 enregistrements sont un
échantillon des données que nous devons traiter dans la verison
finale (qui va contenir environ 2000000 d'enregistrements). Nous
espérons que les temps ne seront pas proportionnels :-(
Sommes-nous les seuls à utiliser SQL/HF7 avec des tables
conséquentes (mais pas énormes, nous n'en sommes pas à +10
milliards d'enregistrements comme sur un autre de nos projets en
Oracle) ? En passant, voilà de quoi faire réflechir pcsoft sur les
performances de HF7 (Oracle renvoie un count de +10 milliards en
0.14s) :
------------------------------------------------------------------
select count(*) from mesures
Result 1 field(s), 1 record(s), time 0.14 sec
count(*)
---------------------
10.006.507.317
------------------------------------------------------------------
En recherchant une solution sur les archives je vois que certains
WDprogrammeurs affirment que le SQL/HF7 est plus lent que les
ordres hyperfile classiques (hLit*). Est-ce réel ? Ce serait-il
une explication à nos problèmes de perf ?
Merci
...
--
Eric Roumégou
http://cerbermail.com/?TSoulBerPA
(cliquez sur le lien ci-dessus pour me contacter en privé)
Bonjour,
Je pense que la vitesse d'insertion est aussi sujette au nombre de
clés et de leur taille dans le fichier concerné.
Avez-vous beaucoup de clés ou de clés ayant les mêmes valeurs dans de
nombreux enregistrements ?
Cordialement
Jean
"..." a écrit dans le message de
news:Notre application effectue des acquisitions de données (de qq
centaines à plusieurs milliers par minute).
Certaines versions devant être exploitées sur des ordinateurs
portables, sur des sites externes, il nous semble préférable
d'utiliser HF7 dans ce contexte, au lieu d'être obligés de demander
à nos client d'installer sur serveur MySQL pour un simple
application monoposte.
Un autre problème que nous rencontrons avec HF7 est que les
performances des insertions diminuent à mesure que la taille de la
BD augmente. Il arrive que nous devions insérer 3000 ou 4000
enregistrements en une minute, mais HF7 ne tient pas la cadence. La
solution de contournement que nous avons est d'écrire nos données
dans un fichier texte, avec un thread secondaire qui relit le
fichier et effectue les insertions au rythme supporté par HF7. Pas
terrible sur le principe, mais ça fonctionne.
Le peu de réponses reçues à nos questions signifierait que ces
performances sont normales ? Pourquoi est on si lent alors qu'on est
très loin des volumes maximums annoncés par PcSoft dans ses
publicités (mensongères?), soit +300 milliards de records ?
"Roumegou" a écrit dans le message de
news:Moi ce que je ne comprends pas, c'est le pourquoi de sortir votre
appli pour mySQL et HF7 ???
Je veux bien comprendre le besoin de s'ouvrir à plusieurs SGBD
standard comme Oracle, sqlserver, mysql, PostgreSQL car ce peut
être un élément de décision pour le client.
Mais HF ? Je doute que cela soit un argument commercial du fait de
la confidentialité de cette base.
Donc pourquoi ne pas proposer que mysql ?
Ou alors, on choisit HF car on doit avoir des installations
monopostes et pour des petites quantités. Il est peut être alors
plus facile d'installer des fichiers HF et les pb de perfs sont
inexistants.
Mais quand on parle de 2000000 d'enreg, la question ne devrait mème
pas se poser, surtout si notre code est dès le depart orienté SQL.
... a exposé le 10/06/2004 :La raison de la lenteur de la première lecture est assez simple
et a été mentionné à plusieures reprises sur ce forum: Windev
ecrit dans un fichier et lit en mémoire chaque ligne du résultat,
tandis que d'autres produits ne lisent que les lignes affichées.
Les lectures suivantes sont trouvé dans le cache et donc plus
rapides.
Une requête de type "select count(*) from table" renvoie 1 valeur
et non un paquet de lignes !
67 secondes pour renvoyer le nombre total de lignes d'une table,
sans aucune clause WHERE est inacceptable (en effet dans ce cas il
est inutile de parcourir les index). En plus ce résultat est
obtenu EN LOCAL (P4 3.2Ghz), alors que le 0.08s en MySql est
obtenu en accédant à une autre machine du RÉSEAU (P3 500Mhz) qui
roule MySQL sous Linux.
Ce qui nous fait peur, c'est que les 427000 enregistrements sont un
échantillon des données que nous devons traiter dans la verison
finale (qui va contenir environ 2000000 d'enregistrements). Nous
espérons que les temps ne seront pas proportionnels :-(
Sommes-nous les seuls à utiliser SQL/HF7 avec des tables
conséquentes (mais pas énormes, nous n'en sommes pas à +10
milliards d'enregistrements comme sur un autre de nos projets en
Oracle) ? En passant, voilà de quoi faire réflechir pcsoft sur les
performances de HF7 (Oracle renvoie un count de +10 milliards en
0.14s) :
------------------------------------------------------------------
select count(*) from mesures
Result 1 field(s), 1 record(s), time 0.14 sec
count(*)
---------------------
10.006.507.317
------------------------------------------------------------------
En recherchant une solution sur les archives je vois que certains
WDprogrammeurs affirment que le SQL/HF7 est plus lent que les
ordres hyperfile classiques (hLit*). Est-ce réel ? Ce serait-il
une explication à nos problèmes de perf ?
Merci
...
--
Eric Roumégou
http://cerbermail.com/?TSoulBerPA
(cliquez sur le lien ci-dessus pour me contacter en privé)
Jean Cougnaud wrote:Bonjour,
Je pense que la vitesse d'insertion est aussi sujette au nombre de
clés et de leur taille dans le fichier concerné.
Avez-vous beaucoup de clés ou de clés ayant les mêmes valeurs dans de
nombreux enregistrements ?
Cordialement
Jean
Salut,
Tu peux effectivement travailler sur des bases de 500 000 enregs en
HF.
Par contre, comme le dit jean Cougnard,
tes bases soient bien décrites dans l'analyse pour que tes requêtes
d'insertions ou autres soient rapides. Tu devrais donc utiliser
l'optimiseur de requête de WINDEV 8 afin de déterminer les bonnes
clés à créer pour chaque fichier. Tu accède à cet outil depuis le
menu « requête.optimiser la requête » de l' éditeur de requête. Tu
peux aussi te pencher sur la commande HOptimiseRequête.
Dans tous les cas, il te suffit de consulter les témoignages de PCS
pour te rendre compte que des bases HF conséquentes sont utilisées.
A+
Antoine.
"..." a écrit dans le message de
news:Notre application effectue des acquisitions de données (de qq
centaines à plusieurs milliers par minute).
Certaines versions devant être exploitées sur des ordinateurs
portables, sur des sites externes, il nous semble préférable
d'utiliser HF7 dans ce contexte, au lieu d'être obligés de demander
à nos client d'installer sur serveur MySQL pour un simple
application monoposte.
Un autre problème que nous rencontrons avec HF7 est que les
performances des insertions diminuent à mesure que la taille de la
BD augmente. Il arrive que nous devions insérer 3000 ou 4000
enregistrements en une minute, mais HF7 ne tient pas la cadence. La
solution de contournement que nous avons est d'écrire nos données
dans un fichier texte, avec un thread secondaire qui relit le
fichier et effectue les insertions au rythme supporté par HF7. Pas
terrible sur le principe, mais ça fonctionne.
Le peu de réponses reçues à nos questions signifierait que ces
performances sont normales ? Pourquoi est on si lent alors qu'on est
très loin des volumes maximums annoncés par PcSoft dans ses
publicités (mensongères?), soit +300 milliards de records ?
"Roumegou" a écrit dans le message de
news:Moi ce que je ne comprends pas, c'est le pourquoi de sortir votre
appli pour mySQL et HF7 ???
Je veux bien comprendre le besoin de s'ouvrir à plusieurs SGBD
standard comme Oracle, sqlserver, mysql, PostgreSQL car ce peut
être un élément de décision pour le client.
Mais HF ? Je doute que cela soit un argument commercial du fait de
la confidentialité de cette base.
Donc pourquoi ne pas proposer que mysql ?
Ou alors, on choisit HF car on doit avoir des installations
monopostes et pour des petites quantités. Il est peut être alors
plus facile d'installer des fichiers HF et les pb de perfs sont
inexistants.
Mais quand on parle de 2000000 d'enreg, la question ne devrait mème
pas se poser, surtout si notre code est dès le depart orienté SQL.
... a exposé le 10/06/2004 :La raison de la lenteur de la première lecture est assez simple
et a été mentionné à plusieures reprises sur ce forum: Windev
ecrit dans un fichier et lit en mémoire chaque ligne du résultat,
tandis que d'autres produits ne lisent que les lignes affichées.
Les lectures suivantes sont trouvé dans le cache et donc plus
rapides.
Une requête de type "select count(*) from table" renvoie 1 valeur
et non un paquet de lignes !
67 secondes pour renvoyer le nombre total de lignes d'une table,
sans aucune clause WHERE est inacceptable (en effet dans ce cas il
est inutile de parcourir les index). En plus ce résultat est
obtenu EN LOCAL (P4 3.2Ghz), alors que le 0.08s en MySql est
obtenu en accédant à une autre machine du RÉSEAU (P3 500Mhz) qui
roule MySQL sous Linux.
Ce qui nous fait peur, c'est que les 427000 enregistrements sont
un échantillon des données que nous devons traiter dans la verison
finale (qui va contenir environ 2000000 d'enregistrements). Nous
espérons que les temps ne seront pas proportionnels :-(
Sommes-nous les seuls à utiliser SQL/HF7 avec des tables
conséquentes (mais pas énormes, nous n'en sommes pas à +10
milliards d'enregistrements comme sur un autre de nos projets en
Oracle) ? En passant, voilà de quoi faire réflechir pcsoft sur les
performances de HF7 (Oracle renvoie un count de +10 milliards en
0.14s) :
------------------------------------------------------------------
select count(*) from mesures
Result 1 field(s), 1 record(s), time 0.14 sec
count(*)
---------------------
10.006.507.317
------------------------------------------------------------------
En recherchant une solution sur les archives je vois que certains
WDprogrammeurs affirment que le SQL/HF7 est plus lent que les
ordres hyperfile classiques (hLit*). Est-ce réel ? Ce serait-il
une explication à nos problèmes de perf ?
Merci
...
--
Eric Roumégou
http://cerbermail.com/?TSoulBerPA
(cliquez sur le lien ci-dessus pour me contacter en privé)
Jean Cougnaud wrote:
Bonjour,
Je pense que la vitesse d'insertion est aussi sujette au nombre de
clés et de leur taille dans le fichier concerné.
Avez-vous beaucoup de clés ou de clés ayant les mêmes valeurs dans de
nombreux enregistrements ?
Cordialement
Jean
Salut,
Tu peux effectivement travailler sur des bases de 500 000 enregs en
HF.
Par contre, comme le dit jean Cougnard,
tes bases soient bien décrites dans l'analyse pour que tes requêtes
d'insertions ou autres soient rapides. Tu devrais donc utiliser
l'optimiseur de requête de WINDEV 8 afin de déterminer les bonnes
clés à créer pour chaque fichier. Tu accède à cet outil depuis le
menu « requête.optimiser la requête » de l' éditeur de requête. Tu
peux aussi te pencher sur la commande HOptimiseRequête.
Dans tous les cas, il te suffit de consulter les témoignages de PCS
pour te rendre compte que des bases HF conséquentes sont utilisées.
A+
Antoine.
"..." <...@...> a écrit dans le message de
news:c568a182f13ffb48ae85c7d8c405d1a6@news.teranews.com...
Notre application effectue des acquisitions de données (de qq
centaines à plusieurs milliers par minute).
Certaines versions devant être exploitées sur des ordinateurs
portables, sur des sites externes, il nous semble préférable
d'utiliser HF7 dans ce contexte, au lieu d'être obligés de demander
à nos client d'installer sur serveur MySQL pour un simple
application monoposte.
Un autre problème que nous rencontrons avec HF7 est que les
performances des insertions diminuent à mesure que la taille de la
BD augmente. Il arrive que nous devions insérer 3000 ou 4000
enregistrements en une minute, mais HF7 ne tient pas la cadence. La
solution de contournement que nous avons est d'écrire nos données
dans un fichier texte, avec un thread secondaire qui relit le
fichier et effectue les insertions au rythme supporté par HF7. Pas
terrible sur le principe, mais ça fonctionne.
Le peu de réponses reçues à nos questions signifierait que ces
performances sont normales ? Pourquoi est on si lent alors qu'on est
très loin des volumes maximums annoncés par PcSoft dans ses
publicités (mensongères?), soit +300 milliards de records ?
"Roumegou" <Utilisezlelien@fin.msg> a écrit dans le message de
news:mn.51f27d4614839a88.11485@fin.msg...
Moi ce que je ne comprends pas, c'est le pourquoi de sortir votre
appli pour mySQL et HF7 ???
Je veux bien comprendre le besoin de s'ouvrir à plusieurs SGBD
standard comme Oracle, sqlserver, mysql, PostgreSQL car ce peut
être un élément de décision pour le client.
Mais HF ? Je doute que cela soit un argument commercial du fait de
la confidentialité de cette base.
Donc pourquoi ne pas proposer que mysql ?
Ou alors, on choisit HF car on doit avoir des installations
monopostes et pour des petites quantités. Il est peut être alors
plus facile d'installer des fichiers HF et les pb de perfs sont
inexistants.
Mais quand on parle de 2000000 d'enreg, la question ne devrait mème
pas se poser, surtout si notre code est dès le depart orienté SQL.
... a exposé le 10/06/2004 :
La raison de la lenteur de la première lecture est assez simple
et a été mentionné à plusieures reprises sur ce forum: Windev
ecrit dans un fichier et lit en mémoire chaque ligne du résultat,
tandis que d'autres produits ne lisent que les lignes affichées.
Les lectures suivantes sont trouvé dans le cache et donc plus
rapides.
Une requête de type "select count(*) from table" renvoie 1 valeur
et non un paquet de lignes !
67 secondes pour renvoyer le nombre total de lignes d'une table,
sans aucune clause WHERE est inacceptable (en effet dans ce cas il
est inutile de parcourir les index). En plus ce résultat est
obtenu EN LOCAL (P4 3.2Ghz), alors que le 0.08s en MySql est
obtenu en accédant à une autre machine du RÉSEAU (P3 500Mhz) qui
roule MySQL sous Linux.
Ce qui nous fait peur, c'est que les 427000 enregistrements sont
un échantillon des données que nous devons traiter dans la verison
finale (qui va contenir environ 2000000 d'enregistrements). Nous
espérons que les temps ne seront pas proportionnels :-(
Sommes-nous les seuls à utiliser SQL/HF7 avec des tables
conséquentes (mais pas énormes, nous n'en sommes pas à +10
milliards d'enregistrements comme sur un autre de nos projets en
Oracle) ? En passant, voilà de quoi faire réflechir pcsoft sur les
performances de HF7 (Oracle renvoie un count de +10 milliards en
0.14s) :
------------------------------------------------------------------
select count(*) from mesures
Result 1 field(s), 1 record(s), time 0.14 sec
count(*)
---------------------
10.006.507.317
------------------------------------------------------------------
En recherchant une solution sur les archives je vois que certains
WDprogrammeurs affirment que le SQL/HF7 est plus lent que les
ordres hyperfile classiques (hLit*). Est-ce réel ? Ce serait-il
une explication à nos problèmes de perf ?
Merci
...
--
Eric Roumégou
http://cerbermail.com/?TSoulBerPA
(cliquez sur le lien ci-dessus pour me contacter en privé)
Jean Cougnaud wrote:Bonjour,
Je pense que la vitesse d'insertion est aussi sujette au nombre de
clés et de leur taille dans le fichier concerné.
Avez-vous beaucoup de clés ou de clés ayant les mêmes valeurs dans de
nombreux enregistrements ?
Cordialement
Jean
Salut,
Tu peux effectivement travailler sur des bases de 500 000 enregs en
HF.
Par contre, comme le dit jean Cougnard,
tes bases soient bien décrites dans l'analyse pour que tes requêtes
d'insertions ou autres soient rapides. Tu devrais donc utiliser
l'optimiseur de requête de WINDEV 8 afin de déterminer les bonnes
clés à créer pour chaque fichier. Tu accède à cet outil depuis le
menu « requête.optimiser la requête » de l' éditeur de requête. Tu
peux aussi te pencher sur la commande HOptimiseRequête.
Dans tous les cas, il te suffit de consulter les témoignages de PCS
pour te rendre compte que des bases HF conséquentes sont utilisées.
A+
Antoine.
"..." a écrit dans le message de
news:Notre application effectue des acquisitions de données (de qq
centaines à plusieurs milliers par minute).
Certaines versions devant être exploitées sur des ordinateurs
portables, sur des sites externes, il nous semble préférable
d'utiliser HF7 dans ce contexte, au lieu d'être obligés de demander
à nos client d'installer sur serveur MySQL pour un simple
application monoposte.
Un autre problème que nous rencontrons avec HF7 est que les
performances des insertions diminuent à mesure que la taille de la
BD augmente. Il arrive que nous devions insérer 3000 ou 4000
enregistrements en une minute, mais HF7 ne tient pas la cadence. La
solution de contournement que nous avons est d'écrire nos données
dans un fichier texte, avec un thread secondaire qui relit le
fichier et effectue les insertions au rythme supporté par HF7. Pas
terrible sur le principe, mais ça fonctionne.
Le peu de réponses reçues à nos questions signifierait que ces
performances sont normales ? Pourquoi est on si lent alors qu'on est
très loin des volumes maximums annoncés par PcSoft dans ses
publicités (mensongères?), soit +300 milliards de records ?
"Roumegou" a écrit dans le message de
news:Moi ce que je ne comprends pas, c'est le pourquoi de sortir votre
appli pour mySQL et HF7 ???
Je veux bien comprendre le besoin de s'ouvrir à plusieurs SGBD
standard comme Oracle, sqlserver, mysql, PostgreSQL car ce peut
être un élément de décision pour le client.
Mais HF ? Je doute que cela soit un argument commercial du fait de
la confidentialité de cette base.
Donc pourquoi ne pas proposer que mysql ?
Ou alors, on choisit HF car on doit avoir des installations
monopostes et pour des petites quantités. Il est peut être alors
plus facile d'installer des fichiers HF et les pb de perfs sont
inexistants.
Mais quand on parle de 2000000 d'enreg, la question ne devrait mème
pas se poser, surtout si notre code est dès le depart orienté SQL.
... a exposé le 10/06/2004 :La raison de la lenteur de la première lecture est assez simple
et a été mentionné à plusieures reprises sur ce forum: Windev
ecrit dans un fichier et lit en mémoire chaque ligne du résultat,
tandis que d'autres produits ne lisent que les lignes affichées.
Les lectures suivantes sont trouvé dans le cache et donc plus
rapides.
Une requête de type "select count(*) from table" renvoie 1 valeur
et non un paquet de lignes !
67 secondes pour renvoyer le nombre total de lignes d'une table,
sans aucune clause WHERE est inacceptable (en effet dans ce cas il
est inutile de parcourir les index). En plus ce résultat est
obtenu EN LOCAL (P4 3.2Ghz), alors que le 0.08s en MySql est
obtenu en accédant à une autre machine du RÉSEAU (P3 500Mhz) qui
roule MySQL sous Linux.
Ce qui nous fait peur, c'est que les 427000 enregistrements sont
un échantillon des données que nous devons traiter dans la verison
finale (qui va contenir environ 2000000 d'enregistrements). Nous
espérons que les temps ne seront pas proportionnels :-(
Sommes-nous les seuls à utiliser SQL/HF7 avec des tables
conséquentes (mais pas énormes, nous n'en sommes pas à +10
milliards d'enregistrements comme sur un autre de nos projets en
Oracle) ? En passant, voilà de quoi faire réflechir pcsoft sur les
performances de HF7 (Oracle renvoie un count de +10 milliards en
0.14s) :
------------------------------------------------------------------
select count(*) from mesures
Result 1 field(s), 1 record(s), time 0.14 sec
count(*)
---------------------
10.006.507.317
------------------------------------------------------------------
En recherchant une solution sur les archives je vois que certains
WDprogrammeurs affirment que le SQL/HF7 est plus lent que les
ordres hyperfile classiques (hLit*). Est-ce réel ? Ce serait-il
une explication à nos problèmes de perf ?
Merci
...
--
Eric Roumégou
http://cerbermail.com/?TSoulBerPA
(cliquez sur le lien ci-dessus pour me contacter en privé)
Dans tous les cas, il te suffit de consulter les témoignages de PCS pour te
rendre compte que des bases HF conséquentes sont utilisées.
Dans tous les cas, il te suffit de consulter les témoignages de PCS pour te
rendre compte que des bases HF conséquentes sont utilisées.
Dans tous les cas, il te suffit de consulter les témoignages de PCS pour te
rendre compte que des bases HF conséquentes sont utilisées.
éditeur de requête. Tu peux aussi te pencher sur la commande
HOptimiseRequête.
Dans tous les cas, il te suffit de consulter les témoignages de PCS pour te
rendre compte que des bases HF conséquentes sont utilisées.
éditeur de requête. Tu peux aussi te pencher sur la commande
HOptimiseRequête.
Dans tous les cas, il te suffit de consulter les témoignages de PCS pour te
rendre compte que des bases HF conséquentes sont utilisées.
éditeur de requête. Tu peux aussi te pencher sur la commande
HOptimiseRequête.
Dans tous les cas, il te suffit de consulter les témoignages de PCS pour te
rendre compte que des bases HF conséquentes sont utilisées.
Antoine wrote:
> éditeur de requête. Tu peux aussi te pencher sur la commande
> HOptimiseRequête.
Salut Antoine, ça fait un moment qu'on s'est pas entendu... Donné la
nature de nos échanges, je dirais, heureusement. Je pense tu sais très
bien que HOptimiseRequête ne sert à rien lorsqu'on compte, totalise ou
trie avec une requête (le départ de ce fil). Certainement dans le cas de
tables fichiers, on est obligé de trier dans la requête car Windev ne le
permet plus sur le résultat (pourquoi pas d'ailleurs). Il serait
beaucoup plus convivial pouvoir trier les fichiers SQL afin de pouvoir
les parcourir dans un sens ou un autre.
Ce qui est intéressant est que le trie ne semble pas avoir d'effet de
rallentissement sur les autres produits que j'avais testé en parallèle.
Les problèmes connus de HF ont à voir directement avec le moteur et ne
pas la structure des données. On peut voir cela très facilement dans des
comparatifs simples avec des ID et indexes sur tous les clés de liaison.
Pour ma part, j'aime utiliser les éditeurs de fenêtre, d'états et de
code de Windev et j'attends avec impatience que les requêtes et le
moteur HF seront porté au niveau d'autres bases de données.
>
>
>
> Dans tous les cas, il te suffit de consulter les témoignages de PCS pour
> rendre compte que des bases HF conséquentes sont utilisées.
Antoine wrote:
> éditeur de requête. Tu peux aussi te pencher sur la commande
> HOptimiseRequête.
Salut Antoine, ça fait un moment qu'on s'est pas entendu... Donné la
nature de nos échanges, je dirais, heureusement. Je pense tu sais très
bien que HOptimiseRequête ne sert à rien lorsqu'on compte, totalise ou
trie avec une requête (le départ de ce fil). Certainement dans le cas de
tables fichiers, on est obligé de trier dans la requête car Windev ne le
permet plus sur le résultat (pourquoi pas d'ailleurs). Il serait
beaucoup plus convivial pouvoir trier les fichiers SQL afin de pouvoir
les parcourir dans un sens ou un autre.
Ce qui est intéressant est que le trie ne semble pas avoir d'effet de
rallentissement sur les autres produits que j'avais testé en parallèle.
Les problèmes connus de HF ont à voir directement avec le moteur et ne
pas la structure des données. On peut voir cela très facilement dans des
comparatifs simples avec des ID et indexes sur tous les clés de liaison.
Pour ma part, j'aime utiliser les éditeurs de fenêtre, d'états et de
code de Windev et j'attends avec impatience que les requêtes et le
moteur HF seront porté au niveau d'autres bases de données.
>
>
>
> Dans tous les cas, il te suffit de consulter les témoignages de PCS pour
> rendre compte que des bases HF conséquentes sont utilisées.
Antoine wrote:
> éditeur de requête. Tu peux aussi te pencher sur la commande
> HOptimiseRequête.
Salut Antoine, ça fait un moment qu'on s'est pas entendu... Donné la
nature de nos échanges, je dirais, heureusement. Je pense tu sais très
bien que HOptimiseRequête ne sert à rien lorsqu'on compte, totalise ou
trie avec une requête (le départ de ce fil). Certainement dans le cas de
tables fichiers, on est obligé de trier dans la requête car Windev ne le
permet plus sur le résultat (pourquoi pas d'ailleurs). Il serait
beaucoup plus convivial pouvoir trier les fichiers SQL afin de pouvoir
les parcourir dans un sens ou un autre.
Ce qui est intéressant est que le trie ne semble pas avoir d'effet de
rallentissement sur les autres produits que j'avais testé en parallèle.
Les problèmes connus de HF ont à voir directement avec le moteur et ne
pas la structure des données. On peut voir cela très facilement dans des
comparatifs simples avec des ID et indexes sur tous les clés de liaison.
Pour ma part, j'aime utiliser les éditeurs de fenêtre, d'états et de
code de Windev et j'attends avec impatience que les requêtes et le
moteur HF seront porté au niveau d'autres bases de données.
>
>
>
> Dans tous les cas, il te suffit de consulter les témoignages de PCS pour
> rendre compte que des bases HF conséquentes sont utilisées.
Ya rien de pire que la publi-information...
Ya rien de pire que la publi-information...
Ya rien de pire que la publi-information...
Si il y a plein de trucs pires !
Par exemple une personne qui passe son temps à être négative sur windev et
son éditeur, et apparamment depuis des années !
C'était juste un clein d'oeil, pour faire remarquer que tu n'as que des
interventions négatives, et que ce n'est pas forcément constructif....
Ces témoignages, c'est trop top !
Ca me fait vraiment plaisir à chaque fois que je les lis, et je me réjouis de
ces gens qui comme moi aiment plutôt windev !
Bonne soirée
Si il y a plein de trucs pires !
Par exemple une personne qui passe son temps à être négative sur windev et
son éditeur, et apparamment depuis des années !
C'était juste un clein d'oeil, pour faire remarquer que tu n'as que des
interventions négatives, et que ce n'est pas forcément constructif....
Ces témoignages, c'est trop top !
Ca me fait vraiment plaisir à chaque fois que je les lis, et je me réjouis de
ces gens qui comme moi aiment plutôt windev !
Bonne soirée
Si il y a plein de trucs pires !
Par exemple une personne qui passe son temps à être négative sur windev et
son éditeur, et apparamment depuis des années !
C'était juste un clein d'oeil, pour faire remarquer que tu n'as que des
interventions négatives, et que ce n'est pas forcément constructif....
Ces témoignages, c'est trop top !
Ca me fait vraiment plaisir à chaque fois que je les lis, et je me réjouis de
ces gens qui comme moi aiment plutôt windev !
Bonne soirée
