[WD 7.5 / 8.0] Requêtes sur Hyperfile et lenteurs réseau
20 réponses
mat
Bonjour,
Nous avons découvert une anomalie concernant les requêtes de Windev sur
Hyperfile et demandé PC Soft aujourd'hui de la corriger.
Préambule: Entre mai et juillet 2003 nous avions fait beaucoup de tests
en réseau, à cause de lenteurs constatées, et communiqué le résultat à
PC Soft. En octobre 2003, la version 75206g éliminait les problèmes
constatés. Au moins nous croyions. Nous sommes maintenant sous WD8 et
après un témoignage récent que le problème persiste lorsqu’un des
fichiers concernés est en modification, nous avons refait nos tests,
aussi avec l'ancien projet WD7.5 sous la version 75206g. Effectivement
le problème existe toujours, et avait déjà existé sous la 206g,
simplement nous n'avions pas testé avec des modifications à l'époque...
Le Service Technique a réagit rapidement à notre communication la
semaine passée, mais il ne répète que le point de vue publié en octobre
2003 sous le nom "Hyperfile sur Serveur Windows" (à trouver sous FAQ
2861). Ce document place la responsabilité pour les lenteurs en réseau
dans le coin de Microsoft Windows (OpLocks) et les développeurs (mauvais
code). Je n'ai aucun doute que ces deux points peuvent jouer un rôle.
Mais nous avons également des expériences avec Paradox, Access, Delphi
et Visual Foxpro. Avec aucun de ces produits nous remarquons des
ralentissements comparables en réseau. Alors, un problème général de
Windows qui se fait noter seulement avec Windev / HF ???
Extraits de ce document, concernant les verrous opportunistes (OpLocks)
de Windows:
..."Un mécanisme important des serveurs Windows est le "verrou
opportuniste". Ce mécanisme est propre aux serveurs Windows et est
totalement indépendant de Windev et de Hyper File."...
..."Il est tout à fait normal de constater des différences de
performances dès la 2° connexion en mode modification. Notez que les
performances, pour un réseau correctement dimensionné, seront identiques
pour 2 ou 50 postes. Les performances sont alors similaires aux réseaux
utilisant d'autres logiciels serveurs: Linux, Novell. C'est le mécanisme
de gestion du verrou opportuniste de Windows qui implique cela."...
CONSTATS
--------
1) Le premier extrait implique que Windev/HF n'y sont pour rien, c'est
la faute à Windows. Mais HF et OpLocks sont aussi indépendant l'un de
l'autre comme Windev de Windows. Nous avons refait des tests sous
Paradox et Access 2000. Aucun de ces environnements ne montre des
ralentissements en réseau comparable à Windev/HF. La même chose valait
l'année passée avec les tests sous Visual Foxpro et Delphi. C'est
clairement une interaction de Windev/HF avec Windows qui est responsable
des ralentissements.
2) Le 2e extrait ne tient pas compte du contexte: oui, le ralentissement
d'une requête est normal lorsqu’un des fichiers est en modification sur
un autre poste. Mais en chiffres ça veut dire quoi ? Chez nous:
Paradox + 16%
Access 2000 + 18%
Windev/HF + 270%
Ces chiffres expliquent pourquoi certains développeurs Windev sont
mécontents. J'aimerais ajouter que la version de Paradox est la 7 de
1996, donc pas exactement une technologie d'avant-garde.
3) Windev cache les lenteurs de ses requêtes en les exécutant en arrière
plan. Mais ceci ne fonctionne plus quand il faut totaliser une rubrique
ou compter les enregistrements rendus ou trier une requête multi-fichier
sur autre chose qu'une clé de liaison. La recommandation de certains
gens qu'un index composé des rubriques de trie résout le problème ne
sert à rien lorsque plusieurs fichiers sont utilisés.
4) Le plus déconcertant est la découverte qu'une requête exécutée sur un
poste client utilise un fichier temporaire sur le SERVEUR, au lieu du
disque local. C'est à notre avis la raison principale des
ralentissements: c'est plus lent d'écrire sur le serveur que sur son
disque local et en plus cela provoque des conflits lors d'un 2e accès
car il doit gérer plusieurs contextes du "même fichier". On peut
facilement vérifier ce comportement: on ouvre la même fenêtre avec une
table alimentée par une requête EN LECTURE SEUL sur le Serveur et un
poste client. On modifie sur le serveur un seul champ de la table et le
temps de réponse de la requête sur le poste client passe IMMéDIATEMENT
au mode "modification multi-utilisateur", donc + 270%, et ceci pour tout
le monde. POURTANT IL N'Y A AUCUNE MODIFICATION DU FICHIER DE DONNÉES,
AVEC UNE REQUÊTE EN LECTURE SEULE, UNIQUEMENT DANS LA TABLE, C'EST-A
DIRE LA REQUETE SUR UN AUTRE PC.
5) Autre indice que les lenteurs de Windev / HF sont faits maison plutôt
que dû au réseau: si le ralentissement venait uniquement du fait que le
serveur doit interrompre le verrou OpLock, alors le retard serait
toujours le même dans le réseau. En réalité le ralentissement en
secondes dépend de la performance du PC client. Alors il s'agit bien
d'une question de traitement et ne pas de réseau!
CONCLUSIONS
-----------
Dès qu'il y a modification d'un des fichiers d'une requête, qu'il faut
obtenir le nombre d'enregistrements, calculer une somme, accéder un
enregistrement vers la fin du fichier SQL ou trier la requête sur autre
chose que la clé de liaison de deux fichiers, les requêtes Windev sur HF
commencent à traîner et parfois deviennent extrêmement longues.
La vérification avec d'autres produits montre que la déclaration de PC
Soft, que cela est le comportement normal sous un serveur Windows est
incorrect. En réalité, il s'agit
- soit du résultat d'une architecture voulu,
- soit d'un dysfonctionnement accidentel,
des requêtes HF, résultant dans l'usage du serveur pour la gestion du
fichier temporaire d'une requête, aussi lorsqu'elle est EN LECTURE
SEULE. Ce comportement est à notre avis responsable pour les importants
ralentissements lors de modifications.
Les autres produits testés ne sont pas perturbés par les OpLocks de
Windows, nous croyons parce qu'ils ne font tout simplement que ce qu'ils
doivent: lire les données sur le serveur, les transférer sur disque
local et les traiter localement. Aucun conflit possible entre le fichier
SQL d'un poste et l'autre.
Nous avons investi beaucoup de temps dans un projet important pour nous
et espérons que les requêtes HF seront mises au point bientôt, une fois
pour toutes. D’autant plus qu’il nous paraît pas difficile de s’assurer
que le fichier temporaire d’une requête en lecture seul réside sur le PC
local et ne pas sur le serveur. Nous pensons qu’avec cela les lenteurs
réclamées vont disparaître.
La version annoncée de client/serveur n'est pas une bonne solution pour
les utilisateurs d'une BD en partage de fichiers, car le traitement des
données fonctionne d'une autre manière et l'application doit être
partiellement réécrite. Si elle était payante, c'est en plus le client
qui devrait payer pour éviter un dysfonctionnement de la version normale.
Mathias Nobs
Résultats détaillés de nos tests
--------------------------------
Serveur : P4, 2.4Ghz
Clients : P1 = PIII, 650Mhz P2 = PIII, 500Mhz
Test Access: Serveur PIII 500Mhz, P1 PIII 650Mhz, P2 P4 2.4Ghz
OS : W2K Pro sur tous les PC
En 2003, le comportement avec données sur NT4 Serveur et W2K
Server à été identique à W2K Pro.
Utilisation OpLocks : Serveur = 1, Clients = 0
Utilisation network cache: Serveur = 1, Clients = 0
Protocole : TCP/IP
Antivirus : désactivé partout
Usage réseau : exclusif pour les tests
Windev HSecurité: par défaut
Manipul.Fichiers: par défaut
Fichiers: Entêtes et lignes de commandes, liés par ID. Même
structures et données pour WD et Paradox. Access2000
structure fichier similaire mais autres données.
Redémarrage du serveur après chaque série d'un produit.
Temps en secondes pour ouvrir la fenêtre mesuré du début des
déclarations globales à l'initialisation de la fenêtre avec affichage
par Info(HNbRec(sql_test),TimeDifference(vStartTime,TimeSys)),
respectivement Info(TimeDifference(vStartTime,TimeSys)).
* continuation de la lecture en arrière plan. Accès aux enregistrements
non lus impossible, sinon même ralentissement que les tests précédents.
** fichier de données MDB déjà ouvert par l'autre poste = accès plus rapide.
Fenêtre Windev créé par le RAD avec une table fichier alimenté par une
requête Windev avec le code SQL suivant:
select * from Contract,ContractDetail
where ContractDetail.IDContract = Contract.IDContract
Lancement de la requête dans les déclarations globales de la fenêtre RAD:
IF HFileExist(sql_test)=False THEN
gbRequeteLocal = True
// Query initialization sql_test
HExecuteQuery(sql_test,hQueryDefault)
IF ErrorOccurred THEN
// Error message display
Error("Error when initializing the query correspondant aux
fichier :
sql_test")
// window closing
Close()
END
ELSE
gbRequeteLocal = False
END
> La version annoncée de client/serveur n'est pas une bonne solution pour les utilisateurs d'une BD en partage de fichiers, car le traitement des données fonctionne d'une autre manière et l'application doit être partiellement réécrite. Si elle était payante, c'est en plus le client qui devrait payer pour éviter un dysfonctionnement de la version normale.
En quoi peux-tu affirmer que l'application doit partiellement être réécrite ? Tu as tester le C/S ? Pour moi il suffirait de plugger les ordres ainsi que les requetes du coté client pour les envoyer sur le serveur. Tout ceci peut facilement être envisageable au moment de la compilation.
Concernant le coût éventuel de cette évolution (C/S) j'attends les nouvelles plaquettes.
Cette remarque n'enlève en rien à la qualité du contenu de ton mail.
-- Emmanuel
> La version annoncée de client/serveur n'est pas une bonne solution
pour
les utilisateurs d'une BD en partage de fichiers, car le traitement
des données fonctionne d'une autre manière et l'application doit être
partiellement réécrite. Si elle était payante, c'est en plus le client
qui devrait payer pour éviter un dysfonctionnement de la version
normale.
En quoi peux-tu affirmer que l'application doit partiellement être réécrite
? Tu as tester le C/S ?
Pour moi il suffirait de plugger les ordres ainsi que les requetes du coté
client pour les envoyer sur le serveur. Tout ceci peut facilement être
envisageable au moment de la compilation.
Concernant le coût éventuel de cette évolution (C/S) j'attends les nouvelles
plaquettes.
Cette remarque n'enlève en rien à la qualité du contenu de ton mail.
> La version annoncée de client/serveur n'est pas une bonne solution pour les utilisateurs d'une BD en partage de fichiers, car le traitement des données fonctionne d'une autre manière et l'application doit être partiellement réécrite. Si elle était payante, c'est en plus le client qui devrait payer pour éviter un dysfonctionnement de la version normale.
En quoi peux-tu affirmer que l'application doit partiellement être réécrite ? Tu as tester le C/S ? Pour moi il suffirait de plugger les ordres ainsi que les requetes du coté client pour les envoyer sur le serveur. Tout ceci peut facilement être envisageable au moment de la compilation.
Concernant le coût éventuel de cette évolution (C/S) j'attends les nouvelles plaquettes.
Cette remarque n'enlève en rien à la qualité du contenu de ton mail.
-- Emmanuel
mat
free wrote:
La version annoncée de client/serveur n'est pas une bonne solution pour les utilisateurs d'une BD en partage de fichiers, car le traitement des données fonctionne d'une autre manière et l'application doit être partiellement réécrite. Si elle était payante, c'est en plus le client qui devrait payer pour éviter un dysfonctionnement de la version normale.
En quoi peux-tu affirmer que l'application doit partiellement être réécrite ? Tu as tester le C/S ? Pour moi il suffirait de plugger les ordres ainsi que les requetes du coté client pour les envoyer sur le serveur. Tout ceci peut facilement être envisageable au moment de la compilation.
Concernant le coût éventuel de cette évolution (C/S) j'attends les nouvelles plaquettes.
Cette remarque n'enlève en rien à la qualité du contenu de ton mail.
-- Emmanuel
Bonjour Emmanuel, Je n'ai pas testé la version C/S. Je me réfère aux nombreux posts en ce qui concerne mySQL, entre autre sur ce forum. J'accèpte volontièrement la preuve du contraire. Tout ce qui aide la cause...
free wrote:
La version annoncée de client/serveur n'est pas une bonne solution
pour
les utilisateurs d'une BD en partage de fichiers, car le traitement
des données fonctionne d'une autre manière et l'application doit être
partiellement réécrite. Si elle était payante, c'est en plus le client
qui devrait payer pour éviter un dysfonctionnement de la version
normale.
En quoi peux-tu affirmer que l'application doit partiellement être réécrite
? Tu as tester le C/S ?
Pour moi il suffirait de plugger les ordres ainsi que les requetes du coté
client pour les envoyer sur le serveur. Tout ceci peut facilement être
envisageable au moment de la compilation.
Concernant le coût éventuel de cette évolution (C/S) j'attends les nouvelles
plaquettes.
Cette remarque n'enlève en rien à la qualité du contenu de ton mail.
--
Emmanuel
Bonjour Emmanuel,
Je n'ai pas testé la version C/S. Je me réfère aux nombreux posts en ce
qui concerne mySQL, entre autre sur ce forum. J'accèpte volontièrement
la preuve du contraire. Tout ce qui aide la cause...
La version annoncée de client/serveur n'est pas une bonne solution pour les utilisateurs d'une BD en partage de fichiers, car le traitement des données fonctionne d'une autre manière et l'application doit être partiellement réécrite. Si elle était payante, c'est en plus le client qui devrait payer pour éviter un dysfonctionnement de la version normale.
En quoi peux-tu affirmer que l'application doit partiellement être réécrite ? Tu as tester le C/S ? Pour moi il suffirait de plugger les ordres ainsi que les requetes du coté client pour les envoyer sur le serveur. Tout ceci peut facilement être envisageable au moment de la compilation.
Concernant le coût éventuel de cette évolution (C/S) j'attends les nouvelles plaquettes.
Cette remarque n'enlève en rien à la qualité du contenu de ton mail.
-- Emmanuel
Bonjour Emmanuel, Je n'ai pas testé la version C/S. Je me réfère aux nombreux posts en ce qui concerne mySQL, entre autre sur ce forum. J'accèpte volontièrement la preuve du contraire. Tout ce qui aide la cause...
free
mat wrote:
free wrote:
La version annoncée de client/serveur n'est pas une bonne solution pour les utilisateurs d'une BD en partage de fichiers, car le traitement des données fonctionne d'une autre manière et l'application doit être partiellement réécrite. Si elle était payante, c'est en plus le client qui devrait payer pour éviter un dysfonctionnement de la version normale.
En quoi peux-tu affirmer que l'application doit partiellement être réécrite ? Tu as tester le C/S ? Pour moi il suffirait de plugger les ordres ainsi que les requetes du coté client pour les envoyer sur le serveur. Tout ceci peut facilement être envisageable au moment de la compilation.
Concernant le coût éventuel de cette évolution (C/S) j'attends les nouvelles plaquettes.
Cette remarque n'enlève en rien à la qualité du contenu de ton mail.
Je n'ai pas testé la version C/S. Je me réfère aux nombreux posts en ce qui concerne mySQL, entre autre sur ce forum. J'accèpte volontièrement la preuve du contraire. Tout ce qui aide la cause...
OK. Pour moi il ne faut pas confondre le C/S de l'éditeur et la programmation avec un SGBD C/S du marché issue d'une migration.
La problématique rencontrée par certains d'entre nous vient du fait même de leur mode de programmation. Quand on programme en mode fichier (à la HF-Like) que ce soit avec HyperFile, avec MySQL, avec Oracle tu auras _TOUJOURS_ des temps quasi comparables. Quand on programme en requetes, il apparait un problème au niveau du langage SQL, chose qui est générale entre les différents SGBD (il suffit de voir les fonctions DECODE de Oracle et IF de MySQL). Autre problème rencontré et que j'ai déjà présenté : certains pensent que l'écriture avec une méga requête va réduire leur temps de traitement ce qui est parfois faux...
Pour moi, dans l'état actuel des choses, il est préférable d'attendre la solution de l'éditeur et de trouver rapidement une réponse à tes questions : quel est l'impact dans mes applications existantes ? quel est le cout ?
-- Emmanuel Lecoester www.sqlmanagerx.com
mat wrote:
free wrote:
La version annoncée de client/serveur n'est pas une bonne solution
pour
les utilisateurs d'une BD en partage de fichiers, car le traitement
des données fonctionne d'une autre manière et l'application doit
être partiellement réécrite. Si elle était payante, c'est en plus
le client qui devrait payer pour éviter un dysfonctionnement de la
version normale.
En quoi peux-tu affirmer que l'application doit partiellement être
réécrite ? Tu as tester le C/S ?
Pour moi il suffirait de plugger les ordres ainsi que les requetes
du coté client pour les envoyer sur le serveur. Tout ceci peut
facilement être envisageable au moment de la compilation.
Concernant le coût éventuel de cette évolution (C/S) j'attends les
nouvelles plaquettes.
Cette remarque n'enlève en rien à la qualité du contenu de ton mail.
Je n'ai pas testé la version C/S. Je me réfère aux nombreux posts en
ce qui concerne mySQL, entre autre sur ce forum. J'accèpte
volontièrement la preuve du contraire. Tout ce qui aide la cause...
OK. Pour moi il ne faut pas confondre le C/S de l'éditeur et la
programmation avec un SGBD C/S du marché issue d'une migration.
La problématique rencontrée par certains d'entre nous vient du fait même de
leur mode de programmation. Quand on programme en mode fichier (à la
HF-Like) que ce soit avec HyperFile, avec MySQL, avec Oracle tu auras
_TOUJOURS_ des temps quasi comparables. Quand on programme en requetes, il
apparait un problème au niveau du langage SQL, chose qui est générale entre
les différents SGBD (il suffit de voir les fonctions DECODE de Oracle et IF
de MySQL). Autre problème rencontré et que j'ai déjà présenté : certains
pensent que l'écriture avec une méga requête va réduire leur temps de
traitement ce qui est parfois faux...
Pour moi, dans l'état actuel des choses, il est préférable d'attendre la
solution de l'éditeur et de trouver rapidement une réponse à tes questions :
quel est l'impact dans mes applications existantes ? quel est le cout ?
La version annoncée de client/serveur n'est pas une bonne solution pour les utilisateurs d'une BD en partage de fichiers, car le traitement des données fonctionne d'une autre manière et l'application doit être partiellement réécrite. Si elle était payante, c'est en plus le client qui devrait payer pour éviter un dysfonctionnement de la version normale.
En quoi peux-tu affirmer que l'application doit partiellement être réécrite ? Tu as tester le C/S ? Pour moi il suffirait de plugger les ordres ainsi que les requetes du coté client pour les envoyer sur le serveur. Tout ceci peut facilement être envisageable au moment de la compilation.
Concernant le coût éventuel de cette évolution (C/S) j'attends les nouvelles plaquettes.
Cette remarque n'enlève en rien à la qualité du contenu de ton mail.
Je n'ai pas testé la version C/S. Je me réfère aux nombreux posts en ce qui concerne mySQL, entre autre sur ce forum. J'accèpte volontièrement la preuve du contraire. Tout ce qui aide la cause...
OK. Pour moi il ne faut pas confondre le C/S de l'éditeur et la programmation avec un SGBD C/S du marché issue d'une migration.
La problématique rencontrée par certains d'entre nous vient du fait même de leur mode de programmation. Quand on programme en mode fichier (à la HF-Like) que ce soit avec HyperFile, avec MySQL, avec Oracle tu auras _TOUJOURS_ des temps quasi comparables. Quand on programme en requetes, il apparait un problème au niveau du langage SQL, chose qui est générale entre les différents SGBD (il suffit de voir les fonctions DECODE de Oracle et IF de MySQL). Autre problème rencontré et que j'ai déjà présenté : certains pensent que l'écriture avec une méga requête va réduire leur temps de traitement ce qui est parfois faux...
Pour moi, dans l'état actuel des choses, il est préférable d'attendre la solution de l'éditeur et de trouver rapidement une réponse à tes questions : quel est l'impact dans mes applications existantes ? quel est le cout ?
-- Emmanuel Lecoester www.sqlmanagerx.com
JBT
Le 21/09/2004, mat a supposé :
free wrote:
La version annoncée de client/serveur n'est pas une bonne solution pour les utilisateurs d'une BD en partage de fichiers, car le traitement des données fonctionne d'une autre manière et l'application doit être partiellement réécrite. Si elle était payante, c'est en plus le client qui devrait payer pour éviter un dysfonctionnement de la version normale.
En quoi peux-tu affirmer que l'application doit partiellement être réécrite ? Tu as tester le C/S ? Pour moi il suffirait de plugger les ordres ainsi que les requetes du coté client pour les envoyer sur le serveur. Tout ceci peut facilement être envisageable au moment de la compilation.
Concernant le coût éventuel de cette évolution (C/S) j'attends les nouvelles plaquettes.
Cette remarque n'enlève en rien à la qualité du contenu de ton mail.
-- Emmanuel
Bonjour Emmanuel, Je n'ai pas testé la version C/S. Je me réfère aux nombreux posts en ce qui concerne mySQL, entre autre sur ce forum. J'accèpte volontièrement la preuve du contraire. Tout ce qui aide la cause...
Merci avant tout "Mat" pour la précision de ton message.
Pour ces raisons j'avais des doutes sur la poursuite de l'utilisation du système de partage actuel. Actuellement je n'avais quasiment que des installations avec Linux/Samba, car là aucun ralentissement de ce type. Avec l'arrivée du client/serveur, je ne suis pas certain qu'un jour nous ayons le fin mot de l'affaire. En effet, aucun ralentissement de ce type n'est constaté en mode client/serveur d'après mes tests. Mais il ne s'agit encore que de la bêta version sur laquelle la communication n'est pas encore possible :-(
--
Le 21/09/2004, mat a supposé :
free wrote:
La version annoncée de client/serveur n'est pas une bonne solution
pour
les utilisateurs d'une BD en partage de fichiers, car le traitement
des données fonctionne d'une autre manière et l'application doit être
partiellement réécrite. Si elle était payante, c'est en plus le client
qui devrait payer pour éviter un dysfonctionnement de la version
normale.
En quoi peux-tu affirmer que l'application doit partiellement être réécrite
? Tu as tester le C/S ?
Pour moi il suffirait de plugger les ordres ainsi que les requetes du coté
client pour les envoyer sur le serveur. Tout ceci peut facilement être
envisageable au moment de la compilation.
Concernant le coût éventuel de cette évolution (C/S) j'attends les
nouvelles
plaquettes.
Cette remarque n'enlève en rien à la qualité du contenu de ton mail.
--
Emmanuel
Bonjour Emmanuel,
Je n'ai pas testé la version C/S. Je me réfère aux nombreux posts en ce qui
concerne mySQL, entre autre sur ce forum. J'accèpte volontièrement la preuve
du contraire. Tout ce qui aide la cause...
Merci avant tout "Mat" pour la précision de ton message.
Pour ces raisons j'avais des doutes sur la poursuite de l'utilisation
du système de partage actuel. Actuellement je n'avais quasiment que des
installations avec Linux/Samba, car là aucun ralentissement de ce type.
Avec l'arrivée du client/serveur, je ne suis pas certain qu'un jour
nous ayons le fin mot de l'affaire. En effet, aucun ralentissement de
ce type n'est constaté en mode client/serveur d'après mes tests. Mais
il ne s'agit encore que de la bêta version sur laquelle la
communication n'est pas encore possible :-(
La version annoncée de client/serveur n'est pas une bonne solution pour les utilisateurs d'une BD en partage de fichiers, car le traitement des données fonctionne d'une autre manière et l'application doit être partiellement réécrite. Si elle était payante, c'est en plus le client qui devrait payer pour éviter un dysfonctionnement de la version normale.
En quoi peux-tu affirmer que l'application doit partiellement être réécrite ? Tu as tester le C/S ? Pour moi il suffirait de plugger les ordres ainsi que les requetes du coté client pour les envoyer sur le serveur. Tout ceci peut facilement être envisageable au moment de la compilation.
Concernant le coût éventuel de cette évolution (C/S) j'attends les nouvelles plaquettes.
Cette remarque n'enlève en rien à la qualité du contenu de ton mail.
-- Emmanuel
Bonjour Emmanuel, Je n'ai pas testé la version C/S. Je me réfère aux nombreux posts en ce qui concerne mySQL, entre autre sur ce forum. J'accèpte volontièrement la preuve du contraire. Tout ce qui aide la cause...
Merci avant tout "Mat" pour la précision de ton message.
Pour ces raisons j'avais des doutes sur la poursuite de l'utilisation du système de partage actuel. Actuellement je n'avais quasiment que des installations avec Linux/Samba, car là aucun ralentissement de ce type. Avec l'arrivée du client/serveur, je ne suis pas certain qu'un jour nous ayons le fin mot de l'affaire. En effet, aucun ralentissement de ce type n'est constaté en mode client/serveur d'après mes tests. Mais il ne s'agit encore que de la bêta version sur laquelle la communication n'est pas encore possible :-(
--
Adrien
j'ai la version bêta du c/s et il suffit de l'installer, copier les fichiers sur le serveur et c'est tout.je n'ai pas touché au code. a premiére vue, les performances sont meilleures, c'est un bon début.
A+ Adrien.
"free" a écrit dans le message de news:4150575b$0$17699$
> La version annoncée de client/serveur n'est pas une bonne solution > pour > les utilisateurs d'une BD en partage de fichiers, car le traitement > des données fonctionne d'une autre manière et l'application doit être > partiellement réécrite. Si elle était payante, c'est en plus le client > qui devrait payer pour éviter un dysfonctionnement de la version > normale.
En quoi peux-tu affirmer que l'application doit partiellement être
réécrite
? Tu as tester le C/S ? Pour moi il suffirait de plugger les ordres ainsi que les requetes du coté client pour les envoyer sur le serveur. Tout ceci peut facilement être envisageable au moment de la compilation.
Concernant le coût éventuel de cette évolution (C/S) j'attends les
nouvelles
plaquettes.
Cette remarque n'enlève en rien à la qualité du contenu de ton mail.
-- Emmanuel
j'ai la version bêta du c/s et il suffit de l'installer, copier les
fichiers sur le serveur et c'est tout.je n'ai pas touché au code.
a premiére vue, les performances sont meilleures, c'est un bon début.
A+
Adrien.
"free" <el@netcourrier.com> a écrit dans le message de
news:4150575b$0$17699$626a14ce@news.free.fr...
> La version annoncée de client/serveur n'est pas une bonne solution
> pour
> les utilisateurs d'une BD en partage de fichiers, car le traitement
> des données fonctionne d'une autre manière et l'application doit être
> partiellement réécrite. Si elle était payante, c'est en plus le client
> qui devrait payer pour éviter un dysfonctionnement de la version
> normale.
En quoi peux-tu affirmer que l'application doit partiellement être
réécrite
? Tu as tester le C/S ?
Pour moi il suffirait de plugger les ordres ainsi que les requetes du coté
client pour les envoyer sur le serveur. Tout ceci peut facilement être
envisageable au moment de la compilation.
Concernant le coût éventuel de cette évolution (C/S) j'attends les
nouvelles
plaquettes.
Cette remarque n'enlève en rien à la qualité du contenu de ton mail.
j'ai la version bêta du c/s et il suffit de l'installer, copier les fichiers sur le serveur et c'est tout.je n'ai pas touché au code. a premiére vue, les performances sont meilleures, c'est un bon début.
A+ Adrien.
"free" a écrit dans le message de news:4150575b$0$17699$
> La version annoncée de client/serveur n'est pas une bonne solution > pour > les utilisateurs d'une BD en partage de fichiers, car le traitement > des données fonctionne d'une autre manière et l'application doit être > partiellement réécrite. Si elle était payante, c'est en plus le client > qui devrait payer pour éviter un dysfonctionnement de la version > normale.
En quoi peux-tu affirmer que l'application doit partiellement être
réécrite
? Tu as tester le C/S ? Pour moi il suffirait de plugger les ordres ainsi que les requetes du coté client pour les envoyer sur le serveur. Tout ceci peut facilement être envisageable au moment de la compilation.
Concernant le coût éventuel de cette évolution (C/S) j'attends les
nouvelles
plaquettes.
Cette remarque n'enlève en rien à la qualité du contenu de ton mail.
-- Emmanuel
Manu
> j'ai la version bêta du c/s et il suffit de l'installer, copier les fichiers sur le serveur et c'est tout.je n'ai pas touché au code. a premiére vue, les performances sont meilleures, c'est un bon début.
Nickel. Cela me conforte dans l'idée d'un non impact sur les dev et implicitement d'un coup moindre ;-)
-- Emmanuel
> j'ai la version bêta du c/s et il suffit de l'installer, copier les
fichiers sur le serveur et c'est tout.je n'ai pas touché au code.
a premiére vue, les performances sont meilleures, c'est un bon début.
Nickel. Cela me conforte dans l'idée d'un non impact sur les dev et
implicitement d'un coup moindre ;-)
> j'ai la version bêta du c/s et il suffit de l'installer, copier les fichiers sur le serveur et c'est tout.je n'ai pas touché au code. a premiére vue, les performances sont meilleures, c'est un bon début.
Nickel. Cela me conforte dans l'idée d'un non impact sur les dev et implicitement d'un coup moindre ;-)
-- Emmanuel
Eric Demeester
dans (in) fr.comp.developpement.agl.windev, "Adrien" ecrivait (wrote) :
Bonsoir Adrien,
j'ai la version bêta du c/s et il suffit de l'installer, copier les fichiers sur le serveur et c'est tout.je n'ai pas touché au code. a premiére vue, les performances sont meilleures, c'est un bon début.
Tu as eu l'opportunité de faire des mesures comparatives de temps d'accès entre HF et HF C/S ?
Amicalement,
-- Eric
dans (in) fr.comp.developpement.agl.windev, "Adrien"
<adrien.titou@ifrance.com> ecrivait (wrote) :
Bonsoir Adrien,
j'ai la version bêta du c/s et il suffit de l'installer, copier les
fichiers sur le serveur et c'est tout.je n'ai pas touché au code.
a premiére vue, les performances sont meilleures, c'est un bon début.
Tu as eu l'opportunité de faire des mesures comparatives de temps
d'accès entre HF et HF C/S ?
dans (in) fr.comp.developpement.agl.windev, "Adrien" ecrivait (wrote) :
Bonsoir Adrien,
j'ai la version bêta du c/s et il suffit de l'installer, copier les fichiers sur le serveur et c'est tout.je n'ai pas touché au code. a premiére vue, les performances sont meilleures, c'est un bon début.
Tu as eu l'opportunité de faire des mesures comparatives de temps d'accès entre HF et HF C/S ?
Amicalement,
-- Eric
Adrien
j'ai normalement pas le droit de communiquer sur la version bêta hf c/s. toutefois, voici un test réél
requête complexe avec jointure. base = 100 000 enregs avec 5 postes accédant à la base en simultané. resultat = 1 000 enregs
HF : 7 s. HF C/S : 2 sec
je te conseilles par contre de te faire ta propre opinion. tu envoie un mail à pcsoft et ils t'envoient leur bêta version.
A+ Adrien.
"Eric Demeester" <eric+ a écrit dans le message de news:
dans (in) fr.comp.developpement.agl.windev, "Adrien" ecrivait (wrote) :
Bonsoir Adrien,
> j'ai la version bêta du c/s et il suffit de l'installer, copier les > fichiers sur le serveur et c'est tout.je n'ai pas touché au code. > a premiére vue, les performances sont meilleures, c'est un bon début.
Tu as eu l'opportunité de faire des mesures comparatives de temps d'accès entre HF et HF C/S ?
Amicalement,
-- Eric
j'ai normalement pas le droit de communiquer sur la version bêta hf c/s.
toutefois, voici un test réél
requête complexe avec jointure.
base = 100 000 enregs avec 5 postes accédant à la base en simultané.
resultat = 1 000 enregs
HF : 7 s.
HF C/S : 2 sec
je te conseilles par contre de te faire ta propre opinion. tu envoie un mail
à pcsoft et ils t'envoient leur bêta version.
A+
Adrien.
"Eric Demeester" <eric+usenet@galacsys.net> a écrit dans le message de
news:v0i3l0hr8ke14p4f2331vfiq0315q6ta4b@4ax.com...
dans (in) fr.comp.developpement.agl.windev, "Adrien"
<adrien.titou@ifrance.com> ecrivait (wrote) :
Bonsoir Adrien,
> j'ai la version bêta du c/s et il suffit de l'installer, copier les
> fichiers sur le serveur et c'est tout.je n'ai pas touché au code.
> a premiére vue, les performances sont meilleures, c'est un bon début.
Tu as eu l'opportunité de faire des mesures comparatives de temps
d'accès entre HF et HF C/S ?
j'ai normalement pas le droit de communiquer sur la version bêta hf c/s. toutefois, voici un test réél
requête complexe avec jointure. base = 100 000 enregs avec 5 postes accédant à la base en simultané. resultat = 1 000 enregs
HF : 7 s. HF C/S : 2 sec
je te conseilles par contre de te faire ta propre opinion. tu envoie un mail à pcsoft et ils t'envoient leur bêta version.
A+ Adrien.
"Eric Demeester" <eric+ a écrit dans le message de news:
dans (in) fr.comp.developpement.agl.windev, "Adrien" ecrivait (wrote) :
Bonsoir Adrien,
> j'ai la version bêta du c/s et il suffit de l'installer, copier les > fichiers sur le serveur et c'est tout.je n'ai pas touché au code. > a premiére vue, les performances sont meilleures, c'est un bon début.
Tu as eu l'opportunité de faire des mesures comparatives de temps d'accès entre HF et HF C/S ?
Amicalement,
-- Eric
ted
Salut,
Ton post semble vouloir être contructif, pourtant il y a pas mal d'incohérences et de points sombres que je me permets de relever.
Car il est vrai que j'aimerai comme tout développeur Windev qui utilise Hyperfile que celui-ci soit toujours plus rapide. Mais des messages comme celui-là peuvent mettre le doute dans l'esprit de personnes qui ne l'utilisent pas. Et c'est en cela que je me permets de te répondre, car Hyperfile est une partie intégrante de nos applications et de ce fait c'est une bonne partie de notre gagne pain.
Notre expérience avec Hyperfile est plus que positive. Les évoltutions qu'il y a eu notament entre la version 5 et la version 7 étaient plus que positives. Il restait à notre goût un point noir pour les réseaux distant, et Pcsoft nous propose enfin une version C/S.
Comme plusieurs personnes te l'ont déjà dit ici tu devrais tester la version C/S. Il semble que tu possèdes des élements de test interressant. Pour passer une application en C/S je t'assure qu'il suffit d'ajouter une ligne dans le code de l'application
Le Service Technique a réagit rapidement à notre communication la semaine passée, mais il ne répète que le point de vue publié en octobre 2003 sous le nom "Hyperfile sur Serveur Windows" (à trouver sous FAQ 2861). identiques pour 2 ou 50 postes. Les performances sont alors similaires aux réseaux utilisant d'autres logiciels serveurs: Linux, Novell. C'est le mécanisme de gestion du verrou opportuniste de Windows qui implique cela."...
Tu sembles mettre en doûte cette partie. As-tu essayé avec d'autres seveur que des serveurs NT. Nous nous l'avons fait, et comme l'indique ce document avec d'autres type de serveurs nous n'avons pas observé de changement brusque des perfomances au deuxième utilisateurs. Il y a donc pour nous bien un lien spécifiques avec les serveurs NT.
l'année passée avec les tests sous Visual Foxpro et Delphi. C'est
ralentissement d'une requête est normal lorsqu’un des fichiers est en modification sur un autre poste. Mais en chiffres ça veut dire quoi ? Chez nous: Paradox + 16% Access 2000 + 18% Windev/HF + 270%
Pour ces deux points, es-tu sûr d'avoir fait les mêmes tests ? Il s'agit de base de données avec les mêmes structures ?
dans notre société, nous avons également fait des tests. Nous avons obtenu des résultat très différents en fonction de la taille des enregistrements. La différence de vitesse se fait sentir pour les fichiers qui ont des enregistrements de petites tailles. Pour des fichiers avec de très gros enregistrements, il y a peu ou même pas de différence. Dans nos test la charnière se trouvait à unne taille d'enregistrement entre 250 et 300 octets. Ce résultat semble cohérent avec un mécanisme de caches désacitvés.
3) Windev cache les lenteurs de ses requêtes en les exécutant en arrière plan.
Je ne trouve pas que cela cache des lenteurs, mais que cela apporte un confort supplémentaire. C'est d'ailleur ce qui est fait par d'autres bases de données telle que Oracle par exemple. Dans une application tu préfères attendre 10 secondes sans ne pourvoir rien faire, ou avoir un début de résultat immédiatement avec la possibilité de choisir dans ce rsultat avant la fin et/ou d'interrompre la recherche pour lancer une autre recherche ?
La recommandation de certains gens qu'un index composé des rubriques de
trie résout le problème ne sert à rien lorsque plusieurs fichiers sont
utilisés.
C'est faux. Si tu as des indexes qui correspondent à tes critères et en plus des indexes qui correspondent a tes tris cela sera plus rapides. Fait des test c'est indéniable. Il est vrai que l'on ne peut pas mettre des index sur toutes les rubriques. Il faut mettre les index sur les rubriques qui sont le plus souvent en critères, et surtout qui sont sucéptibles d'être les plus discréminentes.
4) Le plus déconcertant est la découverte qu'une requête exécutée sur un poste client utilise un fichier temporaire sur le SERVEUR
Nous n'avons jamais constaté ce phénomène. Tu sembles anouveau très affirmatif. Comment se nomme ce fichier et dans quel répertoire est-il créé ? Si tu as raison nous te soutiendrons devant Pcsoft afin de pouvoir paramétrer l'emplacement d'un tel fichier. Mais j'ai un doûte sur l'existence d'un tel fichier temporaire...
5) Autre indice que les lenteurs de Windev / HF sont faits maison plutôt que dû au réseau: si le ralentissement venait uniquement du fait que le serveur doit interrompre le verrou OpLock, alors le retard serait toujours le même dans le réseau. En réalité le ralentissement en secondes dépend de la performance du PC client. Alors il s'agit bien d'une question de traitement et ne pas de réseau!
C'est anouveau faux. La version de Hyperfile que tu utilises n'est pas C/S. Les perfomances dépendrons donc toujours AUSSI du poste client. C'est chaque poste client qui effectue ses propre recherches. Chaque poste client fait des lectures au poste sur lequel sont les fichiers. Les perfomances dépendant donc du poste serveur et des caches qu'il met à disposition, mais aussi de la rapidité avec laquelle les demandes sont effcetuées par le poste client. Shématiquement on peut facilment imaginer comment cela fonctionne : Les données sont lues sur le poste serveur et sont rappatriés sur le poste client. Si les caches sont activés, il peut y avoir plus de données que ce que le client a demandé, et le tout reste dans le cache du poste local. Selon la requête et les données déjà lues, le poste client va faire d'autres lectures sur le serveur (ici variaions possibles en fonction du poste client). S'il y a des élements dans le cache local et que les données à lire sont dans ce cache c'est autant de lecture "instantannées". Sans cache chaque nouvelle lecture représente un nouvel accès au réseau.
CONCLUSIONS -----------
Ma conclusion, est que tu as "oublié" pas mal de chose mais que tu es très affirmatif dans tout ce que tu dis. C'est un peu dommage car l'idée d'apporter ton experience pour faire évoluer Hyperfile n'était pas mauvaise.
La version annoncée de client/serveur n'est pas une bonne solution pour les utilisateurs d'une BD en partage de fichiers, car le traitement des données fonctionne d'une autre manière et l'application doit être partiellement réécrite.
Télécharge la beta et tu verras que c'est faux. Tu n'as pas besoins de changer quoi que se soit à part la connexion.
Tu pourras par la suite utiliser plus de requêtes ou de vues, plutôt que des filtres si tu veux. Mais nos tests nous ont montrés que les filtres et parcours directs fonctionnent très rapidement sans le moindre changenement dans nos codes. De plus les perfomances restent stables seul ou à plusieurs postes. En c/s on devient indépendant des caches du réseau. En plus si avec cette version tu constates toujours tes pb de perf. tu auras de nouveaus arguments, car les "OpsLock" de Windows seront cette fois-ci mis hors de cause.
-- En esperant avoir fait avancé le sujet. ted
Salut,
Ton post semble vouloir être contructif, pourtant il y a pas mal
d'incohérences et de points sombres que je me permets de relever.
Car il est vrai que j'aimerai comme tout développeur Windev qui utilise
Hyperfile que celui-ci soit toujours plus rapide. Mais des messages comme
celui-là peuvent mettre le doute dans l'esprit de personnes qui ne
l'utilisent pas. Et c'est en cela que je me permets de te répondre, car
Hyperfile est une partie intégrante de nos applications et de ce fait
c'est une bonne partie de notre gagne pain.
Notre expérience avec Hyperfile est plus que positive. Les évoltutions
qu'il y a eu notament entre la version 5 et la version 7 étaient plus que
positives. Il restait à notre goût un point noir pour les réseaux
distant, et Pcsoft nous propose enfin une version C/S.
Comme plusieurs personnes te l'ont déjà dit ici tu devrais tester la
version C/S. Il semble que tu possèdes des élements de test interressant.
Pour passer une application en C/S je t'assure qu'il suffit d'ajouter une
ligne dans le code de l'application
Le Service Technique a réagit rapidement à notre communication la
semaine passée, mais il ne répète que le point de vue publié en
octobre 2003 sous le nom "Hyperfile sur Serveur Windows" (à trouver
sous FAQ 2861).
identiques pour 2 ou 50 postes. Les performances sont alors similaires
aux réseaux utilisant d'autres logiciels serveurs: Linux, Novell.
C'est le mécanisme de gestion du verrou opportuniste de Windows qui
implique cela."...
Tu sembles mettre en doûte cette partie. As-tu essayé avec d'autres
seveur que des serveurs NT. Nous nous l'avons fait, et comme l'indique ce
document avec d'autres type de serveurs nous n'avons pas observé de
changement brusque des perfomances au deuxième utilisateurs. Il y a donc
pour nous bien un lien spécifiques avec les serveurs NT.
l'année passée avec les tests sous Visual Foxpro et Delphi. C'est
ralentissement d'une requête est normal lorsqu’un des fichiers est en
modification sur un autre poste. Mais en chiffres ça veut dire quoi ?
Chez nous: Paradox + 16%
Access 2000 + 18%
Windev/HF + 270%
Pour ces deux points, es-tu sûr d'avoir fait les mêmes tests ? Il s'agit
de base de données avec les mêmes structures ?
dans notre société, nous avons également fait des tests.
Nous avons obtenu des résultat très différents en fonction de la taille
des enregistrements.
La différence de vitesse se fait sentir pour les fichiers qui ont des
enregistrements de petites tailles.
Pour des fichiers avec de très gros enregistrements, il y a peu ou même
pas de différence.
Dans nos test la charnière se trouvait à unne taille d'enregistrement
entre 250 et 300 octets.
Ce résultat semble cohérent avec un mécanisme de caches désacitvés.
3) Windev cache les lenteurs de ses requêtes en les exécutant en
arrière plan.
Je ne trouve pas que cela cache des lenteurs, mais que cela apporte un
confort supplémentaire. C'est d'ailleur ce qui est fait par d'autres
bases de données telle que Oracle par exemple.
Dans une application tu préfères attendre 10 secondes sans ne pourvoir
rien faire, ou avoir un début de résultat immédiatement avec la
possibilité de choisir dans ce rsultat avant la fin et/ou d'interrompre
la recherche pour lancer une autre recherche ?
La recommandation de certains gens qu'un index composé des rubriques de
trie résout le problème ne sert à rien lorsque plusieurs fichiers sont
utilisés.
C'est faux. Si tu as des indexes qui correspondent à tes critères et en
plus des indexes qui correspondent a tes tris cela sera plus rapides.
Fait des test c'est indéniable. Il est vrai que l'on ne peut pas mettre
des index sur toutes les rubriques. Il faut mettre les index sur les
rubriques qui sont le plus souvent en critères, et surtout qui sont
sucéptibles d'être les plus discréminentes.
4) Le plus déconcertant est la découverte qu'une requête exécutée sur
un poste client utilise un fichier temporaire sur le SERVEUR
Nous n'avons jamais constaté ce phénomène. Tu sembles anouveau très
affirmatif. Comment se nomme ce fichier et dans quel répertoire est-il
créé ?
Si tu as raison nous te soutiendrons devant Pcsoft afin de pouvoir
paramétrer l'emplacement d'un tel fichier.
Mais j'ai un doûte sur l'existence d'un tel fichier temporaire...
5) Autre indice que les lenteurs de Windev / HF sont faits maison
plutôt que dû au réseau: si le ralentissement venait uniquement du
fait que le serveur doit interrompre le verrou OpLock, alors le retard
serait toujours le même dans le réseau. En réalité le ralentissement
en secondes dépend de la performance du PC client. Alors il s'agit
bien d'une question de traitement et ne pas de réseau!
C'est anouveau faux. La version de Hyperfile que tu utilises n'est pas
C/S. Les perfomances dépendrons donc toujours AUSSI du poste client.
C'est chaque poste client qui effectue ses propre recherches. Chaque
poste client fait des lectures au poste sur lequel sont les fichiers. Les
perfomances dépendant donc du poste serveur et des caches qu'il met à
disposition, mais aussi de la rapidité avec laquelle les demandes sont
effcetuées par le poste client.
Shématiquement on peut facilment imaginer comment cela fonctionne :
Les données sont lues sur le poste serveur et sont rappatriés sur le
poste client. Si les caches sont activés, il peut y avoir plus de données
que ce que le client a demandé, et le tout reste dans le cache du poste
local. Selon la requête et les données déjà lues, le poste client va
faire d'autres lectures sur le serveur (ici variaions possibles en
fonction du poste client). S'il y a des élements dans le cache local et
que les données à lire sont dans ce cache c'est autant de lecture
"instantannées". Sans cache chaque nouvelle lecture représente un nouvel
accès au réseau.
CONCLUSIONS
-----------
Ma conclusion, est que tu as "oublié" pas mal de chose mais que tu es
très affirmatif dans tout ce que tu dis.
C'est un peu dommage car l'idée d'apporter ton experience pour faire
évoluer Hyperfile n'était pas mauvaise.
La version annoncée de client/serveur n'est pas une bonne solution
pour les utilisateurs d'une BD en partage de fichiers, car le
traitement des données fonctionne d'une autre manière et l'application
doit être partiellement réécrite.
Télécharge la beta et tu verras que c'est faux.
Tu n'as pas besoins de changer quoi que se soit à part la connexion.
Tu pourras par la suite utiliser plus de requêtes ou de vues, plutôt que
des filtres si tu veux. Mais nos tests nous ont montrés que les filtres
et parcours directs fonctionnent très rapidement sans le moindre
changenement dans nos codes.
De plus les perfomances restent stables seul ou à plusieurs postes.
En c/s on devient indépendant des caches du réseau.
En plus si avec cette version tu constates toujours tes pb de perf. tu
auras de nouveaus arguments, car les "OpsLock" de Windows seront cette
fois-ci mis hors de cause.
Ton post semble vouloir être contructif, pourtant il y a pas mal d'incohérences et de points sombres que je me permets de relever.
Car il est vrai que j'aimerai comme tout développeur Windev qui utilise Hyperfile que celui-ci soit toujours plus rapide. Mais des messages comme celui-là peuvent mettre le doute dans l'esprit de personnes qui ne l'utilisent pas. Et c'est en cela que je me permets de te répondre, car Hyperfile est une partie intégrante de nos applications et de ce fait c'est une bonne partie de notre gagne pain.
Notre expérience avec Hyperfile est plus que positive. Les évoltutions qu'il y a eu notament entre la version 5 et la version 7 étaient plus que positives. Il restait à notre goût un point noir pour les réseaux distant, et Pcsoft nous propose enfin une version C/S.
Comme plusieurs personnes te l'ont déjà dit ici tu devrais tester la version C/S. Il semble que tu possèdes des élements de test interressant. Pour passer une application en C/S je t'assure qu'il suffit d'ajouter une ligne dans le code de l'application
Le Service Technique a réagit rapidement à notre communication la semaine passée, mais il ne répète que le point de vue publié en octobre 2003 sous le nom "Hyperfile sur Serveur Windows" (à trouver sous FAQ 2861). identiques pour 2 ou 50 postes. Les performances sont alors similaires aux réseaux utilisant d'autres logiciels serveurs: Linux, Novell. C'est le mécanisme de gestion du verrou opportuniste de Windows qui implique cela."...
Tu sembles mettre en doûte cette partie. As-tu essayé avec d'autres seveur que des serveurs NT. Nous nous l'avons fait, et comme l'indique ce document avec d'autres type de serveurs nous n'avons pas observé de changement brusque des perfomances au deuxième utilisateurs. Il y a donc pour nous bien un lien spécifiques avec les serveurs NT.
l'année passée avec les tests sous Visual Foxpro et Delphi. C'est
ralentissement d'une requête est normal lorsqu’un des fichiers est en modification sur un autre poste. Mais en chiffres ça veut dire quoi ? Chez nous: Paradox + 16% Access 2000 + 18% Windev/HF + 270%
Pour ces deux points, es-tu sûr d'avoir fait les mêmes tests ? Il s'agit de base de données avec les mêmes structures ?
dans notre société, nous avons également fait des tests. Nous avons obtenu des résultat très différents en fonction de la taille des enregistrements. La différence de vitesse se fait sentir pour les fichiers qui ont des enregistrements de petites tailles. Pour des fichiers avec de très gros enregistrements, il y a peu ou même pas de différence. Dans nos test la charnière se trouvait à unne taille d'enregistrement entre 250 et 300 octets. Ce résultat semble cohérent avec un mécanisme de caches désacitvés.
3) Windev cache les lenteurs de ses requêtes en les exécutant en arrière plan.
Je ne trouve pas que cela cache des lenteurs, mais que cela apporte un confort supplémentaire. C'est d'ailleur ce qui est fait par d'autres bases de données telle que Oracle par exemple. Dans une application tu préfères attendre 10 secondes sans ne pourvoir rien faire, ou avoir un début de résultat immédiatement avec la possibilité de choisir dans ce rsultat avant la fin et/ou d'interrompre la recherche pour lancer une autre recherche ?
La recommandation de certains gens qu'un index composé des rubriques de
trie résout le problème ne sert à rien lorsque plusieurs fichiers sont
utilisés.
C'est faux. Si tu as des indexes qui correspondent à tes critères et en plus des indexes qui correspondent a tes tris cela sera plus rapides. Fait des test c'est indéniable. Il est vrai que l'on ne peut pas mettre des index sur toutes les rubriques. Il faut mettre les index sur les rubriques qui sont le plus souvent en critères, et surtout qui sont sucéptibles d'être les plus discréminentes.
4) Le plus déconcertant est la découverte qu'une requête exécutée sur un poste client utilise un fichier temporaire sur le SERVEUR
Nous n'avons jamais constaté ce phénomène. Tu sembles anouveau très affirmatif. Comment se nomme ce fichier et dans quel répertoire est-il créé ? Si tu as raison nous te soutiendrons devant Pcsoft afin de pouvoir paramétrer l'emplacement d'un tel fichier. Mais j'ai un doûte sur l'existence d'un tel fichier temporaire...
5) Autre indice que les lenteurs de Windev / HF sont faits maison plutôt que dû au réseau: si le ralentissement venait uniquement du fait que le serveur doit interrompre le verrou OpLock, alors le retard serait toujours le même dans le réseau. En réalité le ralentissement en secondes dépend de la performance du PC client. Alors il s'agit bien d'une question de traitement et ne pas de réseau!
C'est anouveau faux. La version de Hyperfile que tu utilises n'est pas C/S. Les perfomances dépendrons donc toujours AUSSI du poste client. C'est chaque poste client qui effectue ses propre recherches. Chaque poste client fait des lectures au poste sur lequel sont les fichiers. Les perfomances dépendant donc du poste serveur et des caches qu'il met à disposition, mais aussi de la rapidité avec laquelle les demandes sont effcetuées par le poste client. Shématiquement on peut facilment imaginer comment cela fonctionne : Les données sont lues sur le poste serveur et sont rappatriés sur le poste client. Si les caches sont activés, il peut y avoir plus de données que ce que le client a demandé, et le tout reste dans le cache du poste local. Selon la requête et les données déjà lues, le poste client va faire d'autres lectures sur le serveur (ici variaions possibles en fonction du poste client). S'il y a des élements dans le cache local et que les données à lire sont dans ce cache c'est autant de lecture "instantannées". Sans cache chaque nouvelle lecture représente un nouvel accès au réseau.
CONCLUSIONS -----------
Ma conclusion, est que tu as "oublié" pas mal de chose mais que tu es très affirmatif dans tout ce que tu dis. C'est un peu dommage car l'idée d'apporter ton experience pour faire évoluer Hyperfile n'était pas mauvaise.
La version annoncée de client/serveur n'est pas une bonne solution pour les utilisateurs d'une BD en partage de fichiers, car le traitement des données fonctionne d'une autre manière et l'application doit être partiellement réécrite.
Télécharge la beta et tu verras que c'est faux. Tu n'as pas besoins de changer quoi que se soit à part la connexion.
Tu pourras par la suite utiliser plus de requêtes ou de vues, plutôt que des filtres si tu veux. Mais nos tests nous ont montrés que les filtres et parcours directs fonctionnent très rapidement sans le moindre changenement dans nos codes. De plus les perfomances restent stables seul ou à plusieurs postes. En c/s on devient indépendant des caches du réseau. En plus si avec cette version tu constates toujours tes pb de perf. tu auras de nouveaus arguments, car les "OpsLock" de Windows seront cette fois-ci mis hors de cause.
-- En esperant avoir fait avancé le sujet. ted
mat
ted wrote:
Salut,
Ton post semble vouloir être contructif, pourtant il y a pas mal d'incohérences et de points sombres que je me permets de relever.
Salut Ted,
J'espère bien que vous connaissez mieux votre produit que moi. J'aurais pourtant préféré des points plus concrèts de votre part. P.ex. impossible de reproduire le comportement chez nous, etc. Il me semble que vous manquez des arguments objectifs.
Normal que vous n'aimez pas mon style, je n'aime pas le vôtre.
Il n'y a pourtant pas de réponse aux que - Pourquoi ces ralentissements si d'autres produits ne les montrent pas? - Pourquoi parler d'un problème générale de Windows si d'autres produits ne le connaissent pas? - Pourquoi dévier l'attention sur la vitesse en générale? Ceci n'est pas ma préoccupation principale dans le contexte actuel, et vous le savez très bien.
Par contre il y a toujours plus d'indications que le problème est vraiment dû aux OpLocks et que vous n'avez pas de solution.
Salutations Mat
Comme plusieurs personnes te l'ont déjà dit ici tu devrais tester la version C/S. Il semble que tu possèdes des élements de test interressant. Pour passer une application en C/S je t'assure qu'il suffit d'ajouter une ligne dans le code de l'application
Après mon expérience désastreuse avec WD7/7.5 je n'utiliserai plus aucun nouveau produit PC Soft jusqu'il a été commercialisé pendant un certain temps et qu'on entend plus parler de problèmes apparents. En plus, un plus en vitesse n'est pas une assurance qu'il n'y aura pas le même problème après modification de données.
Le Service Technique a réagit rapidement à notre communication la semaine passée, mais il ne répète que le point de vue publié en octobre 2003 sous le nom "Hyperfile sur Serveur Windows" (à trouver sous FAQ 2861). identiques pour 2 ou 50 postes. Les performances sont alors similaires aux réseaux utilisant d'autres logiciels serveurs: Linux, Novell. C'est le mécanisme de gestion du verrou opportuniste de Windows qui implique cela."...
Tu sembles mettre en doûte cette partie. As-tu essayé avec d'autres seveur que des serveurs NT. Nous nous l'avons fait, et comme l'indique ce document avec d'autres type de serveurs nous n'avons pas observé de changement brusque des perfomances au deuxième utilisateurs. Il y a donc pour nous bien un lien spécifiques avec les serveurs NT.
C'est justement ce que je critique: Windev est fait pour Windows et HF n'est pas capable de gérer les requêtes d'une manière normale sous cet OS. D'autres produits n'ont aucun problème avec des données résidant sur NT/W2K Serveur.
ralentissement d'une requête est normal lorsqu’un des fichiers est en modification sur un autre poste. Mais en chiffres ça veut dire quoi ? Chez nous: Paradox + 16% Access 2000 + 18% Windev/HF + 270%
Pour ces deux points, es-tu sûr d'avoir fait les mêmes tests ? Il s'agit de base de données avec les mêmes structures ?
J'ai bien dit que les données des fichiers Windev et Paradox sont les mêmes, (toutes les rubriques des commandes et lignes de commandes). Les données Windev ont été importé de Paradox. Sous Paradox il y a 10% plus d'enregistrements (4428 au lieu de 4041). On ne teste pas la rapidité de la requête, on teste le plus de temps un requête a besoin sur des fichiers modifiés par rapport à des fichiers sans modifications.
dans notre société, nous avons également fait des tests. Nous avons obtenu des résultat très différents en fonction de la taille des enregistrements. La différence de vitesse se fait sentir pour les fichiers qui ont des enregistrements de petites tailles. Pour des fichiers avec de très gros enregistrements, il y a peu ou même pas de différence. Dans nos test la charnière se trouvait à unne taille d'enregistrement entre 250 et 300 octets. Ce résultat semble cohérent avec un mécanisme de caches désacitvés.
Je ne comprends pas ce paragraphe. Si vous avez fait des tests, alors montrez les résultats. Tous nos tests ont été fait sur les mêmes machines, sans changement de configuration. La taille des enregistrements (taille/nb enregistrements, sur fichier compacté), commandes, suivi par lignes de commandes: HF : 614 + 418 = 1032 octets, total 4041 enreg. dans le résultat Paradox: 800 + 334 = 1134 octets, total 4428 ""
Encore une fois, même que je suis triste que les requêtes Windev sur HF prennent plusieurs fois le temps d'autres produits, cela n'est pas en cause: nous parlons du fait que des requêtes en lecture seule ne se comportent pas comme des requêtes en lecture seule.
3) Windev cache les lenteurs de ses requêtes en les exécutant en arrière plan.
Je ne trouve pas que cela cache des lenteurs, mais que cela apporte un confort supplémentaire. C'est d'ailleur ce qui est fait par d'autres bases de données telle que Oracle par exemple. Dans une application tu préfères attendre 10 secondes sans ne pourvoir rien faire, ou avoir un début de résultat immédiatement avec la possibilité de choisir dans ce rsultat avant la fin et/ou d'interrompre la recherche pour lancer une autre recherche ?
C'est hors contexte et tu le sais: si je dois accéder p.ex. au dernier enregistrement ou s'il y a une autre situation décrit dans mon post d'origine, tu doit attendre de toute façon tes 10 secondes.
La recommandation de certains gens qu'un index composé des rubriques de
trie résout le problème ne sert à rien lorsque plusieurs fichiers sont
utilisés.
C'est faux. Si tu as des indexes qui correspondent à tes critères et en plus des indexes qui correspondent a tes tris cela sera plus rapides. Fait des test c'est indéniable. Il est vrai que l'on ne peut pas mettre des index sur toutes les rubriques. Il faut mettre les index sur les rubriques qui sont le plus souvent en critères, et surtout qui sont sucéptibles d'être les plus discréminentes.
Encore hors contexte. Je ne dis pas que les index ne servent à rien. Je dis qu'ils n'aident pas à retrouver la vitesse lorsque on utilise des clés de liaison entre deux fichiers: p.ex. en relie commandes et lignes de commandes par l'ID. Aucun problème de faire un tri descendant sur l'ID, le résultat est rapide. Mais le moment que tu tries sur la date, qui a bien un index mais ne se trouve que dans un des deux fichiers, alors la requête se ralentisse énormément. D'ailleurs c'est un autre comportement que nous n'avons jamais vu avec d'autres produits. Le trie de la requête ne ralenti pas les requête de la même façon que Windev. Mais ça c'est aussi hors contexte actuellement.
4) Le plus déconcertant est la découverte qu'une requête exécutée sur un poste client utilise un fichier temporaire sur le SERVEUR
Nous n'avons jamais constaté ce phénomène. Tu sembles anouveau très affirmatif. Comment se nomme ce fichier et dans quel répertoire est-il créé ? Si tu as raison nous te soutiendrons devant Pcsoft afin de pouvoir paramétrer l'emplacement d'un tel fichier. Mais j'ai un doûte sur l'existence d'un tel fichier temporaire...
J'ai évidemment un problème de m'exprimer correctement. Avec un peu de bonne volonté, et une reproduction chez soi en cas de doute, j'espère qu'on arrive quand-même de comprendre mon message.
Il est pour moi secondaire s'il s'agit d'un fichier ou d'une table de verrous ou de contrôle. Le fait est qu'une fois des fichiers ont été modifiés en réseau, la gestion de ces fichiers lors d'accès ultérieurs en lecture seule change. Un seul utilisateur, aucun problème, s'il y a d'autres, et tous également en lecture seule, les temps d'accès dégradent de nouveau. PLUS PERSONNE EST EN MODIFICATION! mais le comportement comme si quelqu'un était en modification persiste.
La seule façon de rétablir la vitesse initiale de l'accès multi-utilisateur en "lecture seule" est de redémarrer le serveur. De ce fait le terme "fichier temporaire" sur le serveur.
Si vous me dites qu'il est impossible de reproduire ce comportement, c'est une chose et probablement vous pourrez nous aider à trouver la raison pourquoi c'est le cas chez nous.
Si vous dites que ce comportement est normal sous Windows Server, je ne suis pas d'accord. Après les tests fait à ce jour, je pense je peux dire tranquillement que c'est faux et si vous insistez sur ce point sans fournir des preuves au contraire, je classe cetted declaration comme mensonge.
5) Autre indice que les lenteurs de Windev / HF sont faits maison plutôt que dû au réseau: si le ralentissement venait uniquement du fait que le serveur doit interrompre le verrou OpLock, alors le retard serait toujours le même dans le réseau. En réalité le ralentissement en secondes dépend de la performance du PC client. Alors il s'agit bien d'une question de traitement et ne pas de réseau!
C'est anouveau faux. La version de Hyperfile que tu utilises n'est pas C/S. Les perfomances dépendrons donc toujours AUSSI du poste client. C'est chaque poste client qui effectue ses propre recherches. Chaque poste client fait des lectures au poste sur lequel sont les fichiers. Les perfomances dépendant donc du poste serveur et des caches qu'il met à disposition, mais aussi de la rapidité avec laquelle les demandes sont effcetuées par le poste client. Shématiquement on peut facilment imaginer comment cela fonctionne : Les données sont lues sur le poste serveur et sont rappatriés sur le poste client. Si les caches sont activés, il peut y avoir plus de données que ce que le client a demandé, et le tout reste dans le cache du poste local. Selon la requête et les données déjà lues, le poste client va faire d'autres lectures sur le serveur (ici variaions possibles en fonction du poste client). S'il y a des élements dans le cache local et que les données à lire sont dans ce cache c'est autant de lecture "instantannées". Sans cache chaque nouvelle lecture représente un nouvel accès au réseau.
Merci pour ces explications. C'est une affirmation que les requêtes Windev sur HF utilisent volontairement le système des OpLocks de Windows lorsque il est disponible. C'est là la différence avec d'autres produits. Je dirais qu'eux s'en fichent de OpLocks. Une requête exécuté sur un poste est toujours envoyée au serveur qui ensuite toujours envoie les données. Le poste ne prend jamais les données d'une requête provenant du serveur du cache locale! Que ça se passe plus vite lorsque une requête est exécuté plusieures fois sur le même poste, devrait être dû au fait que le serveur trouve les même données dans son cache, mais pas parce que le poste trouve les donnés dans son cache. Certes, il y a bcp de chose que ne comprends pas, mais il ne faut pas être Einstein pour comprendre cette situation.
Je répète que tous nos test ont été exécuté avec l'usage du cache réseau et OpLocks activé sur le serveur (paramètres LanManServer) et désactivés sur les postes (paramètres LanManWorkstation et Rdir).
Si vous dites que c'est le comportement normal sous les OS serveur de Windows pour des requêtes en lecture seul, moi je dis que non, ce n'est pas le comportement normal et celui d'autres produits sous les mêmes conditions le prouvent.
En principe ça m'est égale comment sont gérée les requêtes, mais il faut que c'est efficace, sans pénaliser l'utilisation multi-utilisateurs.
ted wrote:
Salut,
Ton post semble vouloir être contructif, pourtant il y a pas mal
d'incohérences et de points sombres que je me permets de relever.
Salut Ted,
J'espère bien que vous connaissez mieux votre produit que moi. J'aurais
pourtant préféré des points plus concrèts de votre part. P.ex.
impossible de reproduire le comportement chez nous, etc. Il me semble
que vous manquez des arguments objectifs.
Normal que vous n'aimez pas mon style, je n'aime pas le vôtre.
Il n'y a pourtant pas de réponse aux que
- Pourquoi ces ralentissements si d'autres produits ne les montrent pas?
- Pourquoi parler d'un problème générale de Windows si d'autres
produits ne le connaissent pas?
- Pourquoi dévier l'attention sur la vitesse en générale? Ceci n'est
pas ma préoccupation principale dans le contexte actuel, et vous le
savez très bien.
Par contre il y a toujours plus d'indications que le problème est
vraiment dû aux OpLocks et que vous n'avez pas de solution.
Salutations
Mat
Comme plusieurs personnes te l'ont déjà dit ici tu devrais tester la
version C/S. Il semble que tu possèdes des élements de test interressant.
Pour passer une application en C/S je t'assure qu'il suffit d'ajouter une
ligne dans le code de l'application
Après mon expérience désastreuse avec WD7/7.5 je n'utiliserai plus aucun
nouveau produit PC Soft jusqu'il a été commercialisé pendant un certain
temps et qu'on entend plus parler de problèmes apparents. En plus, un
plus en vitesse n'est pas une assurance qu'il n'y aura pas le même
problème après modification de données.
Le Service Technique a réagit rapidement à notre communication la
semaine passée, mais il ne répète que le point de vue publié en
octobre 2003 sous le nom "Hyperfile sur Serveur Windows" (à trouver
sous FAQ 2861).
identiques pour 2 ou 50 postes. Les performances sont alors similaires
aux réseaux utilisant d'autres logiciels serveurs: Linux, Novell.
C'est le mécanisme de gestion du verrou opportuniste de Windows qui
implique cela."...
Tu sembles mettre en doûte cette partie. As-tu essayé avec d'autres
seveur que des serveurs NT. Nous nous l'avons fait, et comme l'indique ce
document avec d'autres type de serveurs nous n'avons pas observé de
changement brusque des perfomances au deuxième utilisateurs. Il y a donc
pour nous bien un lien spécifiques avec les serveurs NT.
C'est justement ce que je critique: Windev est fait pour Windows et HF
n'est pas capable de gérer les requêtes d'une manière normale sous cet
OS. D'autres produits n'ont aucun problème avec des données résidant sur
NT/W2K Serveur.
ralentissement d'une requête est normal lorsqu’un des fichiers est en
modification sur un autre poste. Mais en chiffres ça veut dire quoi ?
Chez nous: Paradox + 16%
Access 2000 + 18%
Windev/HF + 270%
Pour ces deux points, es-tu sûr d'avoir fait les mêmes tests ? Il s'agit
de base de données avec les mêmes structures ?
J'ai bien dit que les données des fichiers Windev et Paradox sont les
mêmes, (toutes les rubriques des commandes et lignes de commandes). Les
données Windev ont été importé de Paradox. Sous Paradox il y a 10% plus
d'enregistrements (4428 au lieu de 4041). On ne teste pas la rapidité de
la requête, on teste le plus de temps un requête a besoin sur des
fichiers modifiés par rapport à des fichiers sans modifications.
dans notre société, nous avons également fait des tests.
Nous avons obtenu des résultat très différents en fonction de la taille
des enregistrements.
La différence de vitesse se fait sentir pour les fichiers qui ont des
enregistrements de petites tailles.
Pour des fichiers avec de très gros enregistrements, il y a peu ou même
pas de différence.
Dans nos test la charnière se trouvait à unne taille d'enregistrement
entre 250 et 300 octets.
Ce résultat semble cohérent avec un mécanisme de caches désacitvés.
Je ne comprends pas ce paragraphe. Si vous avez fait des tests, alors
montrez les résultats. Tous nos tests ont été fait sur les mêmes
machines, sans changement de configuration. La taille des
enregistrements (taille/nb enregistrements, sur fichier compacté),
commandes, suivi par lignes de commandes:
HF : 614 + 418 = 1032 octets, total 4041 enreg. dans le résultat
Paradox: 800 + 334 = 1134 octets, total 4428 ""
Encore une fois, même que je suis triste que les requêtes Windev sur HF
prennent plusieurs fois le temps d'autres produits, cela n'est pas en
cause: nous parlons du fait que des requêtes en lecture seule ne se
comportent pas comme des requêtes en lecture seule.
3) Windev cache les lenteurs de ses requêtes en les exécutant en
arrière plan.
Je ne trouve pas que cela cache des lenteurs, mais que cela apporte un
confort supplémentaire. C'est d'ailleur ce qui est fait par d'autres
bases de données telle que Oracle par exemple.
Dans une application tu préfères attendre 10 secondes sans ne pourvoir
rien faire, ou avoir un début de résultat immédiatement avec la
possibilité de choisir dans ce rsultat avant la fin et/ou d'interrompre
la recherche pour lancer une autre recherche ?
C'est hors contexte et tu le sais: si je dois accéder p.ex. au dernier
enregistrement ou s'il y a une autre situation décrit dans mon post
d'origine, tu doit attendre de toute façon tes 10 secondes.
La recommandation de certains gens qu'un index composé des rubriques de
trie résout le problème ne sert à rien lorsque plusieurs fichiers sont
utilisés.
C'est faux. Si tu as des indexes qui correspondent à tes critères et en
plus des indexes qui correspondent a tes tris cela sera plus rapides.
Fait des test c'est indéniable. Il est vrai que l'on ne peut pas mettre
des index sur toutes les rubriques. Il faut mettre les index sur les
rubriques qui sont le plus souvent en critères, et surtout qui sont
sucéptibles d'être les plus discréminentes.
Encore hors contexte. Je ne dis pas que les index ne servent à rien. Je
dis qu'ils n'aident pas à retrouver la vitesse lorsque on utilise des
clés de liaison entre deux fichiers: p.ex. en relie commandes et lignes
de commandes par l'ID. Aucun problème de faire un tri descendant sur
l'ID, le résultat est rapide. Mais le moment que tu tries sur la date,
qui a bien un index mais ne se trouve que dans un des deux fichiers,
alors la requête se ralentisse énormément. D'ailleurs c'est un autre
comportement que nous n'avons jamais vu avec d'autres produits. Le trie
de la requête ne ralenti pas les requête de la même façon que Windev.
Mais ça c'est aussi hors contexte actuellement.
4) Le plus déconcertant est la découverte qu'une requête exécutée sur
un poste client utilise un fichier temporaire sur le SERVEUR
Nous n'avons jamais constaté ce phénomène. Tu sembles anouveau très
affirmatif. Comment se nomme ce fichier et dans quel répertoire est-il
créé ?
Si tu as raison nous te soutiendrons devant Pcsoft afin de pouvoir
paramétrer l'emplacement d'un tel fichier.
Mais j'ai un doûte sur l'existence d'un tel fichier temporaire...
J'ai évidemment un problème de m'exprimer correctement. Avec un peu de
bonne volonté, et une reproduction chez soi en cas de doute, j'espère
qu'on arrive quand-même de comprendre mon message.
Il est pour moi secondaire s'il s'agit d'un fichier ou d'une table de
verrous ou de contrôle. Le fait est qu'une fois des fichiers ont été
modifiés en réseau, la gestion de ces fichiers lors d'accès ultérieurs
en lecture seule change. Un seul utilisateur, aucun problème, s'il y a
d'autres, et tous également en lecture seule, les temps d'accès
dégradent de nouveau. PLUS PERSONNE EST EN MODIFICATION! mais le
comportement comme si quelqu'un était en modification persiste.
La seule façon de rétablir la vitesse initiale de l'accès
multi-utilisateur en "lecture seule" est de redémarrer le serveur. De ce
fait le terme "fichier temporaire" sur le serveur.
Si vous me dites qu'il est impossible de reproduire ce comportement,
c'est une chose et probablement vous pourrez nous aider à trouver la
raison pourquoi c'est le cas chez nous.
Si vous dites que ce comportement est normal sous Windows Server, je ne
suis pas d'accord. Après les tests fait à ce jour, je pense je peux dire
tranquillement que c'est faux et si vous insistez sur ce point sans
fournir des preuves au contraire, je classe cetted declaration comme
mensonge.
5) Autre indice que les lenteurs de Windev / HF sont faits maison
plutôt que dû au réseau: si le ralentissement venait uniquement du
fait que le serveur doit interrompre le verrou OpLock, alors le retard
serait toujours le même dans le réseau. En réalité le ralentissement
en secondes dépend de la performance du PC client. Alors il s'agit
bien d'une question de traitement et ne pas de réseau!
C'est anouveau faux. La version de Hyperfile que tu utilises n'est pas
C/S. Les perfomances dépendrons donc toujours AUSSI du poste client.
C'est chaque poste client qui effectue ses propre recherches. Chaque
poste client fait des lectures au poste sur lequel sont les fichiers. Les
perfomances dépendant donc du poste serveur et des caches qu'il met à
disposition, mais aussi de la rapidité avec laquelle les demandes sont
effcetuées par le poste client.
Shématiquement on peut facilment imaginer comment cela fonctionne :
Les données sont lues sur le poste serveur et sont rappatriés sur le
poste client. Si les caches sont activés, il peut y avoir plus de données
que ce que le client a demandé, et le tout reste dans le cache du poste
local. Selon la requête et les données déjà lues, le poste client va
faire d'autres lectures sur le serveur (ici variaions possibles en
fonction du poste client). S'il y a des élements dans le cache local et
que les données à lire sont dans ce cache c'est autant de lecture
"instantannées". Sans cache chaque nouvelle lecture représente un nouvel
accès au réseau.
Merci pour ces explications. C'est une affirmation que les requêtes
Windev sur HF utilisent volontairement le système des OpLocks de Windows
lorsque il est disponible. C'est là la différence avec d'autres
produits. Je dirais qu'eux s'en fichent de OpLocks. Une requête exécuté
sur un poste est toujours envoyée au serveur qui ensuite toujours envoie
les données. Le poste ne prend jamais les données d'une requête
provenant du serveur du cache locale! Que ça se passe plus vite lorsque
une requête est exécuté plusieures fois sur le même poste, devrait être
dû au fait que le serveur trouve les même données dans son cache, mais
pas parce que le poste trouve les donnés dans son cache. Certes, il y a
bcp de chose que ne comprends pas, mais il ne faut pas être Einstein
pour comprendre cette situation.
Je répète que tous nos test ont été exécuté avec l'usage du cache réseau
et OpLocks activé sur le serveur (paramètres LanManServer) et désactivés
sur les postes (paramètres LanManWorkstation et Rdir).
Si vous dites que c'est le comportement normal sous les OS serveur de
Windows pour des requêtes en lecture seul, moi je dis que non, ce n'est
pas le comportement normal et celui d'autres produits sous les mêmes
conditions le prouvent.
En principe ça m'est égale comment sont gérée les requêtes, mais il faut
que c'est efficace, sans pénaliser l'utilisation multi-utilisateurs.
Ton post semble vouloir être contructif, pourtant il y a pas mal d'incohérences et de points sombres que je me permets de relever.
Salut Ted,
J'espère bien que vous connaissez mieux votre produit que moi. J'aurais pourtant préféré des points plus concrèts de votre part. P.ex. impossible de reproduire le comportement chez nous, etc. Il me semble que vous manquez des arguments objectifs.
Normal que vous n'aimez pas mon style, je n'aime pas le vôtre.
Il n'y a pourtant pas de réponse aux que - Pourquoi ces ralentissements si d'autres produits ne les montrent pas? - Pourquoi parler d'un problème générale de Windows si d'autres produits ne le connaissent pas? - Pourquoi dévier l'attention sur la vitesse en générale? Ceci n'est pas ma préoccupation principale dans le contexte actuel, et vous le savez très bien.
Par contre il y a toujours plus d'indications que le problème est vraiment dû aux OpLocks et que vous n'avez pas de solution.
Salutations Mat
Comme plusieurs personnes te l'ont déjà dit ici tu devrais tester la version C/S. Il semble que tu possèdes des élements de test interressant. Pour passer une application en C/S je t'assure qu'il suffit d'ajouter une ligne dans le code de l'application
Après mon expérience désastreuse avec WD7/7.5 je n'utiliserai plus aucun nouveau produit PC Soft jusqu'il a été commercialisé pendant un certain temps et qu'on entend plus parler de problèmes apparents. En plus, un plus en vitesse n'est pas une assurance qu'il n'y aura pas le même problème après modification de données.
Le Service Technique a réagit rapidement à notre communication la semaine passée, mais il ne répète que le point de vue publié en octobre 2003 sous le nom "Hyperfile sur Serveur Windows" (à trouver sous FAQ 2861). identiques pour 2 ou 50 postes. Les performances sont alors similaires aux réseaux utilisant d'autres logiciels serveurs: Linux, Novell. C'est le mécanisme de gestion du verrou opportuniste de Windows qui implique cela."...
Tu sembles mettre en doûte cette partie. As-tu essayé avec d'autres seveur que des serveurs NT. Nous nous l'avons fait, et comme l'indique ce document avec d'autres type de serveurs nous n'avons pas observé de changement brusque des perfomances au deuxième utilisateurs. Il y a donc pour nous bien un lien spécifiques avec les serveurs NT.
C'est justement ce que je critique: Windev est fait pour Windows et HF n'est pas capable de gérer les requêtes d'une manière normale sous cet OS. D'autres produits n'ont aucun problème avec des données résidant sur NT/W2K Serveur.
ralentissement d'une requête est normal lorsqu’un des fichiers est en modification sur un autre poste. Mais en chiffres ça veut dire quoi ? Chez nous: Paradox + 16% Access 2000 + 18% Windev/HF + 270%
Pour ces deux points, es-tu sûr d'avoir fait les mêmes tests ? Il s'agit de base de données avec les mêmes structures ?
J'ai bien dit que les données des fichiers Windev et Paradox sont les mêmes, (toutes les rubriques des commandes et lignes de commandes). Les données Windev ont été importé de Paradox. Sous Paradox il y a 10% plus d'enregistrements (4428 au lieu de 4041). On ne teste pas la rapidité de la requête, on teste le plus de temps un requête a besoin sur des fichiers modifiés par rapport à des fichiers sans modifications.
dans notre société, nous avons également fait des tests. Nous avons obtenu des résultat très différents en fonction de la taille des enregistrements. La différence de vitesse se fait sentir pour les fichiers qui ont des enregistrements de petites tailles. Pour des fichiers avec de très gros enregistrements, il y a peu ou même pas de différence. Dans nos test la charnière se trouvait à unne taille d'enregistrement entre 250 et 300 octets. Ce résultat semble cohérent avec un mécanisme de caches désacitvés.
Je ne comprends pas ce paragraphe. Si vous avez fait des tests, alors montrez les résultats. Tous nos tests ont été fait sur les mêmes machines, sans changement de configuration. La taille des enregistrements (taille/nb enregistrements, sur fichier compacté), commandes, suivi par lignes de commandes: HF : 614 + 418 = 1032 octets, total 4041 enreg. dans le résultat Paradox: 800 + 334 = 1134 octets, total 4428 ""
Encore une fois, même que je suis triste que les requêtes Windev sur HF prennent plusieurs fois le temps d'autres produits, cela n'est pas en cause: nous parlons du fait que des requêtes en lecture seule ne se comportent pas comme des requêtes en lecture seule.
3) Windev cache les lenteurs de ses requêtes en les exécutant en arrière plan.
Je ne trouve pas que cela cache des lenteurs, mais que cela apporte un confort supplémentaire. C'est d'ailleur ce qui est fait par d'autres bases de données telle que Oracle par exemple. Dans une application tu préfères attendre 10 secondes sans ne pourvoir rien faire, ou avoir un début de résultat immédiatement avec la possibilité de choisir dans ce rsultat avant la fin et/ou d'interrompre la recherche pour lancer une autre recherche ?
C'est hors contexte et tu le sais: si je dois accéder p.ex. au dernier enregistrement ou s'il y a une autre situation décrit dans mon post d'origine, tu doit attendre de toute façon tes 10 secondes.
La recommandation de certains gens qu'un index composé des rubriques de
trie résout le problème ne sert à rien lorsque plusieurs fichiers sont
utilisés.
C'est faux. Si tu as des indexes qui correspondent à tes critères et en plus des indexes qui correspondent a tes tris cela sera plus rapides. Fait des test c'est indéniable. Il est vrai que l'on ne peut pas mettre des index sur toutes les rubriques. Il faut mettre les index sur les rubriques qui sont le plus souvent en critères, et surtout qui sont sucéptibles d'être les plus discréminentes.
Encore hors contexte. Je ne dis pas que les index ne servent à rien. Je dis qu'ils n'aident pas à retrouver la vitesse lorsque on utilise des clés de liaison entre deux fichiers: p.ex. en relie commandes et lignes de commandes par l'ID. Aucun problème de faire un tri descendant sur l'ID, le résultat est rapide. Mais le moment que tu tries sur la date, qui a bien un index mais ne se trouve que dans un des deux fichiers, alors la requête se ralentisse énormément. D'ailleurs c'est un autre comportement que nous n'avons jamais vu avec d'autres produits. Le trie de la requête ne ralenti pas les requête de la même façon que Windev. Mais ça c'est aussi hors contexte actuellement.
4) Le plus déconcertant est la découverte qu'une requête exécutée sur un poste client utilise un fichier temporaire sur le SERVEUR
Nous n'avons jamais constaté ce phénomène. Tu sembles anouveau très affirmatif. Comment se nomme ce fichier et dans quel répertoire est-il créé ? Si tu as raison nous te soutiendrons devant Pcsoft afin de pouvoir paramétrer l'emplacement d'un tel fichier. Mais j'ai un doûte sur l'existence d'un tel fichier temporaire...
J'ai évidemment un problème de m'exprimer correctement. Avec un peu de bonne volonté, et une reproduction chez soi en cas de doute, j'espère qu'on arrive quand-même de comprendre mon message.
Il est pour moi secondaire s'il s'agit d'un fichier ou d'une table de verrous ou de contrôle. Le fait est qu'une fois des fichiers ont été modifiés en réseau, la gestion de ces fichiers lors d'accès ultérieurs en lecture seule change. Un seul utilisateur, aucun problème, s'il y a d'autres, et tous également en lecture seule, les temps d'accès dégradent de nouveau. PLUS PERSONNE EST EN MODIFICATION! mais le comportement comme si quelqu'un était en modification persiste.
La seule façon de rétablir la vitesse initiale de l'accès multi-utilisateur en "lecture seule" est de redémarrer le serveur. De ce fait le terme "fichier temporaire" sur le serveur.
Si vous me dites qu'il est impossible de reproduire ce comportement, c'est une chose et probablement vous pourrez nous aider à trouver la raison pourquoi c'est le cas chez nous.
Si vous dites que ce comportement est normal sous Windows Server, je ne suis pas d'accord. Après les tests fait à ce jour, je pense je peux dire tranquillement que c'est faux et si vous insistez sur ce point sans fournir des preuves au contraire, je classe cetted declaration comme mensonge.
5) Autre indice que les lenteurs de Windev / HF sont faits maison plutôt que dû au réseau: si le ralentissement venait uniquement du fait que le serveur doit interrompre le verrou OpLock, alors le retard serait toujours le même dans le réseau. En réalité le ralentissement en secondes dépend de la performance du PC client. Alors il s'agit bien d'une question de traitement et ne pas de réseau!
C'est anouveau faux. La version de Hyperfile que tu utilises n'est pas C/S. Les perfomances dépendrons donc toujours AUSSI du poste client. C'est chaque poste client qui effectue ses propre recherches. Chaque poste client fait des lectures au poste sur lequel sont les fichiers. Les perfomances dépendant donc du poste serveur et des caches qu'il met à disposition, mais aussi de la rapidité avec laquelle les demandes sont effcetuées par le poste client. Shématiquement on peut facilment imaginer comment cela fonctionne : Les données sont lues sur le poste serveur et sont rappatriés sur le poste client. Si les caches sont activés, il peut y avoir plus de données que ce que le client a demandé, et le tout reste dans le cache du poste local. Selon la requête et les données déjà lues, le poste client va faire d'autres lectures sur le serveur (ici variaions possibles en fonction du poste client). S'il y a des élements dans le cache local et que les données à lire sont dans ce cache c'est autant de lecture "instantannées". Sans cache chaque nouvelle lecture représente un nouvel accès au réseau.
Merci pour ces explications. C'est une affirmation que les requêtes Windev sur HF utilisent volontairement le système des OpLocks de Windows lorsque il est disponible. C'est là la différence avec d'autres produits. Je dirais qu'eux s'en fichent de OpLocks. Une requête exécuté sur un poste est toujours envoyée au serveur qui ensuite toujours envoie les données. Le poste ne prend jamais les données d'une requête provenant du serveur du cache locale! Que ça se passe plus vite lorsque une requête est exécuté plusieures fois sur le même poste, devrait être dû au fait que le serveur trouve les même données dans son cache, mais pas parce que le poste trouve les donnés dans son cache. Certes, il y a bcp de chose que ne comprends pas, mais il ne faut pas être Einstein pour comprendre cette situation.
Je répète que tous nos test ont été exécuté avec l'usage du cache réseau et OpLocks activé sur le serveur (paramètres LanManServer) et désactivés sur les postes (paramètres LanManWorkstation et Rdir).
Si vous dites que c'est le comportement normal sous les OS serveur de Windows pour des requêtes en lecture seul, moi je dis que non, ce n'est pas le comportement normal et celui d'autres produits sous les mêmes conditions le prouvent.
En principe ça m'est égale comment sont gérée les requêtes, mais il faut que c'est efficace, sans pénaliser l'utilisation multi-utilisateurs.
