[WD 7.5 / 8.0] Requêtes sur Hyperfile et lenteurs réseau

Bonjour,

J'ai malheureusement oublié de copier mon post sur de Windev-Forum du 22
septembre 23:49. Le voici:


mat wrote:

> CONSTATS
> --------
> ... 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.
>

Bonsoir,

J'ai été contacté par PC Soft parce qu'il ne comprennent pas le début du
paragraphe ci-dessus. Selon leurs ingénieurs c'est impossible qu'un
fichier temporaire est écrit sur le serveur.

En effet, il s'agit d'une déduction de ma part à partir de deux faits et
je m'excuse pour l'imprécision de ma formulation.

1) Pendant nos nombreux tests en 2003, nous avions aussi une
configuration avec les données sur un PC sous W98SE et un poste client
sous W2K Pro. Malheureusement j'ai perdu ce protocole. Lorsque la
fenêtre était déjà ouverte sous W98SE, l'ouverture sous W2K plantait (ou
à l'inverse), disant que le fichier "NomRequête" était verrouillé (sur
le "serveur"). Ceci nous faisait penser que la requête essaye d'utiliser
un fichier sur le serveur (pas nécessairement écrire). Il est bien
possible qu'il y ait une autre raison pour ce comportement, mais à
l'époque, nous avions reçu l'info du ST que dans certains cas Windev
n'obtenait pas la taille correcte du disque local et utilisait le disque
du serveur. Dans mon rapport du 2 juillet 2003 au STG j'ai communiqué
une impression que cette modification dans la table faisait déclencher
les OpLocks de Windows, chose qui ne se produit pas avec les BD d'autres
produits.

2) Également sous WD8, la modification d'une table fichier alimentée par
une requête en lecture seule ouverte sur le serveur réussit à ralentir
immédiatement l'exécution de la même requête sur les postes clients.
Ceci veut dire qu'il y a bien une interférence du serveur sur les
requêtes en lecture seule exécutés sur d'autres PC. Je répète, les
fichiers de données ne sont pas touchés, uniquement la table sur le
serveur, liée à une requête en lecture seule qui devrait normalement se
trouver uniquement en mémoire du poste en question, et probablement sous
forme de fichier sur le poste local...



Grâce à la patience de l'interlocutaire de PC Soft, car je dois avouer
que moi je commence occasionnellement de la perdre, je pense l'entretien
a quand-même été constructif. A la fin du compte leur observation m'a
fait remarquer la différence fondamentale entre les tables/grid des
autres producteurs et celles que j'utilise sous Windev. Les dernières
sont des tables fichier et les premières de "type table/grid mémoire",
mais seulement lorsqu'une requête est concerné.

Peut-être, le problème vient de la gestion de la table et ne pas de la
requête. Le résultat reste bien sûr le même, mais éventuellement ça
aidera à découvrir plus facilement la source de l'ennui. PC Soft
semblent prendre la chose au sérieux. Selon eux il n'y a pas de raison
que ces ralentissements devraient se produire, même avec une table fichier.

Mat
---------------------------------------------------------------------
Pour tout savoir sur windev-forum... Pour se désabonner...
Une seule adresse : http://www.teaser.fr/~edemeester/wdfaq.htm

Bonjour,

J'ai fait deux nouveaux séries de tests, cette fois incluant deux tables
mémoires, une fois avec la table permettant la saisie, une fois en
affichage seulement.

J'ai eu deux surprises avec la table fichier:

1) En modifiant la table fichier sur le serveur, je ne peux plus
reproduire le passage dans le ralentissement maximal comme la dernière
fois à plusieurs reprises.

2) Pour les nouveaux tests, le nombre d'enregistrements a été limité
avec un filtre SQL "AND DATE >= 20000101 ", donnant un résultat de 476
enregistrements. Après modification des fichiers sur un autre PC mon
poste client P1 passait "normalement" dans le ralentissement maximale et
affichait le nombre de lignes de la table, ainsi que le temps de 4.3
secondes. Régulièrement. Mais aussi régulièrement, il recevait encore
des données du serveur pendant 19-20 secondes. Ceci continuait même en
fermant la fenêtre et s'arrêtait seulement en quittant l'application.

Hier, j'ai fait une autre série de tests après recompilation du
projet et d'une nouvelle exe. Ce phénomène a disparu. Le transfert de
donnés s'arrête maintenant avec l'affichage des 476 enregistrements.


Table mémoire
-------------
J'ai d'abord essayé FichierVersTableMémoire. Sur les 4041
enregistrements le temps de chargement était de 11 secondes, en local.
Alors, j'ai abandonné cette fonction et selon recommandation de Rolf
Hentschel utilisé les commandes "manuels" pour remplir la table. Ceci
est le code dans l'initialisation de la fenêtre. J'ai trouve que c'était
un peu plus vite que de le faire dans les déclarations globales. Je n'ai
par contre pas trouvé de différence en mettant la table invisible, comme
j'ai lu quelque part, non plus dans les déclarations globales. Peut-être
ça dépend où se trouve le code.

Table..Visible = Faux
TableSupprimeTout(Table)
POUR TOUS sql_test SUR "IDContract"
TableAjouteLigne(Table,Rubrique1,Rubrique...,Rubrique10)
FIN
Table..Visible = Vrai
Info(Table..Occurrence,HeureDifférence(vStartTime,HeureSys))


Requête de sélection:
select * from Contract,ContractDetail
where ContractDetail.IDContract = Contract.IDContract
and Contract.Date >= '20000101'


Voici les résultats (partout 476 enregistrement dans le résultat, sauf
les premiers 2)
P2 lecture P2 écriture
Test P1 lecture P1 lecture P1 lecture
-----------------------------------------------------------
4041 enregistrements
Table fichier* 5.5 7.0 +27% 24.6 +347/+251% (22.9.)
Table fichier* 8.7 10.7+23% 41.0 +370/+283% (23.9.)?

476 enregistr. (1.2-1.4) (4.2-4.3)
Table fichier* 1.3 1.5 +15% 4.2 +223/+180%

Table mémoire (0.8-1) (0.8-1)
"Affich. seul." 0.9 0.9 2.5 +178%

Table mémoire 1.0 1.2 +20% 2.7 +170%/+125%
"saisie"

Paradox7 0.7 0.7 0.8 +14%
476 enreg.

(*) Pas de différence constaté entre table "saisie" et table en
"affichage seul".


Constats
--------
1) Le ralentissement avec le(s) fichier(s) en modification n'est pas
linéaire. La dégradation de performance en pourcentage pour les 476
enregistrements est moindre que celle des 4041 enr.

2) Ce n'est pas nécessaire que quelqu'un soit en modification/ajout pour
être pénalisé par le ralentissement. Il suffit que deux postes se
connectent avec une table en affichage/requête en lecture seule. La
seule façon que nous avons trouvé pour retrouver le temps d'affichage
correct est de redémarrer le serveur.

3) Les tables mémoires montrent le même phénomène, mais en moindre
mesure. En utilisant TableAjouteLigne, l'affichage d'une table mémoire
est plus rapide que celle d'une table fichier (-30%, ou bien table
fichier + 44%). Avec les fichiers en modification, table mémoire = -40%,
ou table fichier = + 68%.

4) Dans le cas de tables mémoires, il semble qu'une table en "mode
affichage seule" donne un léger avantage dans le temps d'affichage sur
une table permettant la saisie. Cette différence n'est pas du tout
apparente pour une table fichier.

5) Les résultats de la table fichier ont beaucoup varié d'un jour à
l'autre sans raison apparente. Peut-être parce que hier j'ai compilé le
projet avant chaque nouvelle création de l'exécutable afin d'éviter des
comportements étranges expérimentés avant-hier?


Les tests ont encore confirmé la forte dégradation de performance d'une
requête en lecture seule après les fichiers ont été modifiés. Ils
n'ont pas confirmés les soupçons mentionné avant-hier en ce qui concerne
la modification de la table sur le serveur. La chose qui reste est que
voulu ou pas, les requêtes de Windev sur HF sont influencés par les
OpLocks, tandis que d'autres produits ne le sont pas.

Mat

Petite correction:

mat wrote:

> Constats
> --------
> 2) Ce n'est pas nécessaire que quelqu'un soit en modification/ajout
> pour être pénalisé par le ralentissement. Il suffit que deux postes
se > connectent avec une table en affichage/requête en lecture seule. La
> seule façon que nous avons trouvé pour retrouver le temps d'affichage
> correct est de redémarrer le serveur.


svp lire:

1ère ligne: ...pas nécessaire que quelqu'un RESTE en modification/ajout
pour...

2e ligne: ... il suffit que deux AUTRES postes se connectent...

mat <NoSpam-mnobs@bluemail.ch> écrivait news:41541b9f_3@news.bluewin.ch:


Salut,

J'espère bien que vous connaissez mieux votre produit que moi.

Désolés mais ce n'est pas mon produit, même si j'aimerai bien. Je suis un
utilisateur content et qui aime défendre son outil de développement car
c'est aussi son gagne pain.

J'aurais pourtant préféré des points plus concrèts de votre part.
P.ex. impossible de reproduire le comportement chez nous, etc.

Je n'ai jamais dit cela. Ce que je dit c'est que nos tests ne montrent
pas exactement la même chose que les tiens. Et que les résultats varient
en fonctions de la taille des rubriques.

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?

j'aimerai conaitre la réponse, et je pense que Pcsoft aussi.
Car nous constatons nous ausi un ralentissement, mais celui-ci permet
quand même une utilisation normal de l'application.

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.

Mon but est d'apporté le maximum d'indications aux autres développeurs
(et à Pcsoft) de façon a ce que chacun puisse avoir des applications les
plus perfomantes possibles.
Je n'ai effectivement pas de solution, pas plus que toi d'ailleur.

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.

C'est un choix. Mais la personne ne te demande pas d'acheter un maj pour
commercialiser ton application avec. Nous sommes plusieurs à te dire
qu'il est possible de faire un test avec une version gratuite. Ce test
pourrait te rassurer et rassurer d'autres développeurs. Moi le premier,
si tu me dis que tu continues à avoir des pb je ne serai pas rassuré,
mais si tu dis que tu n'as plus de pb cela me rassurera.
Nos tests nous ont montré un plus de vitesse comme tu dis, mais nous ont
aussi montré que le problème après modification des données n'est plus
présent. La version C/S permet de faire des modification et de tester
cette configuration !

en cause: nous parlons du fait que des requêtes en lecture seule ne se
comportent pas comme des requêtes en lecture seule.

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.

Non, pour rétablir la vitesse lié au mécanisme OpsLock, il faut que tous
les processus qui ont ouvert le fichier le referme. C'est ce que j'ai
constaté et ce que Microsoft docummente :

http://msdn.microsoft.com/library/en-
us/fileio/base/opportunistic_locks.asp

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.

Et pourtant je le prouve.
Je ne sais pas ce qui est utilisé dans Hyper File. Mais ci-dessous je
donne un code W-Langag qui utilise les fonctions de base de l'API pour la
gestions des fichiers. Ce code permet de reproduire le phénomène.
Ceux qui veulent le convertir dans un autre lanage peuvent le faire,
c'est sans rapport avec le langage.

Ce code permet au chois de faire une lecture sur un fichier ou de faire
un petit blocage sur un fichier. Pour utiliser ce code et mettre le
phénomène en évidence, il faut l'exécuter comme suit :
- Test mono-utilisation
Sur un poste faire une lecture en étant seul sur le fichier

- Test multi-utilisation
Sur un poste faire un blocage d'un octet du fichier
Sur l'autre poste faire une lecture du même fichier.


//Variable pour chronomtrage
sHeureDebut,sHeureFin sont des DateHeures
//Compteur du nombre de lecture
eNbLectures est un entier
//Handle du fichier manipul
eHandleFichier est un entier
//Nom du fichier manipul
sNomFichier est une chane
//Type d'ouverture du fichier (L/E)
eTypeOuverture est un entier
//Constantes Windows pour le type d'ouverture
GENERIC_READ est un entier=(0x80000000)
GENERIC_WRITE est un entier=(0x40000000)
//Type de partage du fichier
eTypePartage est un entier
//Constantes Windows pour le type de partage
FILE_SHARE_READ est un entier=(0x00000001)
FILE_SHARE_WRITE est un entier=(0x00000002)
//pointeur sur une structure pour les process qui hrite de ce handle.
NULL car pas d'autres process.
eSecuriteNonUtilse est un entier=Null
//Mthode de cration / d'ouverture (similaire HCration ou
HCreationSiInexistant ou HOuvre...)
eTypeCreation est un entier
//Constantes Windows pour le type de cration
CREATE_NEW est un entier=1
CREATE_ALWAYS est un entier=2
OPEN_EXISTING est un entier=3
OPEN_ALWAYS est un entier=4
TRUNCATE_EXISTING est un entier=5
//Paramtres du cache systeme
eAttributsCache est un entier
//Constantes Windows pour les ttributs et le cache system
FILE_ATTRIBUTE_READONLY est un entier=0x00000001
FILE_ATTRIBUTE_HIDDEN est un entier=0x00000002
FILE_ATTRIBUTE_SYSTEM est un entier=0x00000004
FILE_ATTRIBUTE_DIRECTORY est un entier=0x00000010
FILE_ATTRIBUTE_ARCHIVE est un entier=0x00000020
FILE_ATTRIBUTE_NORMAL est un entier=0x00000080
FILE_ATTRIBUTE_TEMPORARY est un entier=0x00000100

//Type d'accs
//Accs de type "alatoire"
FILE_FLAG_RANDOM_ACCESS est un entier=0x10000000
//Accs de type squentiel
FILE_FLAG_SEQUENTIAL_SCAN est un entier=0x08000000

//Constantes non dispo sus 95/98/Me :
FILE_FLAG_BACKUP_SEMANTICS est un entier=0x02000000
//Constantes concernant les caches
//Pour ne pas utiliser les caches systemes
FILE_FLAG_NO_BUFFERING est un entier=0x20000000 //Ecriture
directe sans les caches system
//Attention dans ce cas il faut faire les lecture par un multiple de la
taille d'un secteur (GetDiskFreeSpace pour aavoir la taille d'un secteur)
FILE_FLAG_OVERLAPPED est un entier=0x40000000 //traitement
asynchrone de L/E
FILE_FLAG_WRITE_THROUGH est un entier=0x80000000 //Ecrit dans les
cache et flush les caches
//Constantes Handle invalide
INVALID_HANDLE_VALUE est un entier=-1
//Template : Non support sous 95/98/Me
hTemplateFile est un entier=Null

//Pour la lecture
sChaineLue est une chane
eNbOctetsUnEnreg est un entier
eNbOctetsLus est un entier
lpOverlapped est un entier=Null //Pour les L/E asynchrone

//Contante Windows pour le positionement dans le fichier
FILE_BEGIN est un entier=0
FILE_CURRENT est un entier=1
FILE_END est un entier=2

//Pour la rcupration des informations sur le disque destination (Fonction
de l'API "GetDiskFreeSpace")
eNbSecteursParCluster est un entier
eNbOctetsParSecteur est un entier
eNbClustersLibres est un entier
eNbTotalDeClusters est un entier


//********************** Pour 'API <LockFileEx> :
LOCKFILE_EXCLUSIVE_LOCK est un entier=2
LOCKFILE_FAIL_IMMEDIATELY est un entier=1

eTypeBlocage est un entier=LOCKFILE_FAIL_IMMEDIATELY
eReserv est un entier=0
ePartieBasseNbOctetsaBloquer est un entier=1
ePartieHauteNbOctetsaBloquer est un entier=0

StrOVERLAPPED est un compose de
Internal est un entier=0
InternalHigh est un entier=0
ePartieBassePositionFichier est un entier=1
ePartieHautePositionFichier est un entier=0
hEvent est un entier=0
FIN
//**********************


bLecture est un boolen
ePosRes est un entier
eNbMaxLecture est un entier

//Fichier manipuler
sNomFichier=fSlecteur("", "", "Sélectionnez un fichier...", "Tous
fichiers (*.*)"+TAB+"*.*"+RC+"Hyper File (*.fic)"+TAB+"*.FIC", "FIC",
fselOuvre+fselExiste)
//fichier sélectionné ?
SI sNomFichier="" ALORS
RETOUR
FIN
//---Avec une fenêtre qui contient un super champ de sélection de fichier
on peut mettre
//sNomFichier=SCSelecteurFichier.SAIS_FIC

eNbOctetsUnEnreg0// Taille d'un enregistrement
//---Avec une fentre qui contient un champ de saisie on peut mettre :
//eNbOctetsUnEnreg=CHPTAILLEENREG// Taille d'un enregistrement


bLecture=OuiNon("Que voulez-vous faire ? "+RC+"- Lire le fichier :
OUI"+RC+"- Ouvrir et bloquer une partie du fichier : NON (dans ce cas une
fenêtre Info conserve le fichier bloqué pour permettre le lancement d'un
test de lecture depuis un autre poste)")


eNbMaxLecture000
//---Avec une fentre qui contient un champ de saisie on peut mettre :
//eNbMaxLecture=CHPNBMAXLECTURE

//---- Paramtres d'ouverture du fichier
//Ouverture en L/E
eTypeOuverture=GENERIC_READ+GENERIC_WRITE
//Partage en L/E
eTypePartage=FILE_SHARE_WRITE+FILE_SHARE_READ
eSecuriteNonUtilse=Null //pas utilisé
//Ouvre si le fichier existe dj
eTypeCreation=OPEN_EXISTING
//Accès en attribut normal, accès "alatoire" (une lecture "classique" est
ordonnées sur l'index mais pas sur les données)
eAttributsCache=FILE_ATTRIBUTE_NORMAL+FILE_FLAG_RANDOM_ACCESS
//Ouverture du fichier
eHandleFichier=AppelDLL32("KERNEL32","CreateFileA",&sNomFichier,...

eTypeOuverture,eTypePartage,eSecuriteNonUtilse,eTypeCreation,eAttrib
utsCache,hTemplateFile)
//Fichier bien ouvert ?
SI eHandleFichier=INVALID_HANDLE_VALUE ALORS
Erreur("Erreur d'ouverture du fichier",ErreurInfo())
RETOUR
FIN

//Lecture
SI bLecture ALORS

//On met la taille la chaine qui va "rcptionner" les valeurs lues
sChaineLue=Complte("",eNbOctetsUnEnreg)
BoucleParcours : //Label pour GOTO
//RAZ compteur du nombre de lectures
eNbLectures=0
//Début Chrono
sHeureDebutÚteSys()+HeureSys()
BOUCLE
//Lecture d'un enregistrement
SI PAS AppelDLL32("KERNEL32","ReadFile",eHandleFichier,
&sChaineLue,eNbOctetsUnEnreg,&eNbOctetsLus,lpOverlapped) ALORS
Erreur("Erreur de lecture",ErreurInfo())
SORTIR
FIN

//Fin de fichier ?
SI eNbOctetsLus=0 ALORS SORTIR //fin de fichier

//Enregistrement suivant
eNbLectures++
SI eNbLectures=eNbMaxLecture ALORS SORTIR
FIN
//Fin Chrono
sHeureFinÚteSys()+HeureSys()
//Affichage du rsultat
//La fermeture du fichier ne se fera qu'aprés validation afin de
pouvoir faire un test en parallèle sur un autre poste avant la fermeture
du fichier
SI OuiNon(eNbLectures+" lectures en "+DuréeVersChane(sHeureFin-
sHeureDebut,"J.HH:MM'SS''LLL"),"Recommencer ? Sinon fermeture du
fichier.") ALORS
//on se repositionne au début du fichier
API
("KERNEL32","SetFilePointer",eHandleFichier,0,Null,FILE_BEGIN)
//on recommence
GOTO BoucleParcours
FIN
SINON
//Blocage
//Lecture d'un octet
sChaineLue=" "
eNbOctetsUnEnreg=1
SI PAS AppelDLL32("KERNEL32","ReadFile",eHandleFichier,
&sChaineLue,eNbOctetsUnEnreg,&eNbOctetsLus,lpOverlapped) ALORS
Erreur("Erreur de lecture",ErreurInfo())
SINON
//on bloc en écriture : eTypeBlocage=0
SI PAS API
("KERNEL32","LockFileEx",eHandleFichier,eTypeBlocage,eReserv,ePartieBasse
NbOctetsaBloquer,ePartieHauteNbOctetsaBloquer,&StrOVERLAPPED) ALORS
Erreur("Erreur de blocage",ErreurInfo())
SINON
Info("Fichier bloqué. Lancez un test de lecture depuis un
autre poste. Une fois le test terminé cliquez sur OK pour femer le
fichier.")
FIN
FIN
FIN

//Fermeture du fichier
SI PAS AppelDLL32("KERNEL32","CloseHandle",eHandleFichier) ALORS
Erreur("Pb de fermeture du fichier",ErreurInfo())
FIN



--
En esperant avoir fait avancé tout le monde.
ted

Bonjour Ted,

J'ai également visité le KB de MS et trouvé des informations similaires.
Peut-être on avancera un peu.

Voici encore ce que je trouve bizarre.

1) Est-ce qu'il s'agit vraiment d'un problème OpLocks ou pas? Il est
confirmé dans la doc Microsoft que les OpLocks sont toujours
demandé du client ou d'une application. Pour des raisons de sécurité
beaucoup de gens recommandent depuis longtemps de désactiver les OpLocks
et le Cache Réseau sur les postes accédant des serveurs NT/W2K. Nous
avons donc cette situation et de notre coté, les postes clients ne
demandent pas les OpLocks. Voici les paramètres du poste P1 utilisé dans
lest tests:
[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServiceslanmanworkstationparameters]
"enableplaintextpassword"=dword:00000000
"enablesecuritysignature"=dword:00000001
"requiresecuritysignature"=dword:00000000
"OtherDomains"=hex(7):00,00
"UtilizeNtCaching"=dword:00000000
"UseOpportunisticLocking"=dword:00000000
Mais de toute façon, le poste ne peut pas ouvrir les fichiers HF sans
intervention du DLL HF, alors c'est là où le type d'accès est défini.

2) J'ai souvent compilé le projet et tout à coup il m'a donné un warning
sur une variable locale dans une fonction qui cache une variable globale
de la fenêtre. Ce code date du 15/9 et la variable globale du 4/9 et
jamais reçu ce message auparavant.

Autre effet: après des tests rapides avec hFerme("") et mettre/ne pas
mettre HAnnuleDéclaration, la rapidité de la requête fichier a tout à
coup été amélioré notablement. Le comportement est toujours le même,
mais la vitesse maintenant égale à celle de la table mémoire: ~0.9 sec
en lecture mono-poste, ~1.0 sec en lecture multiposte, ~2.5 sec en
lecture sur P1 avec modif sur P2.

L'essai de provoquer de nouveau un ralentissement n'apporte rien. Après
plusieurs compilations, les temps d'exécution restent le même. N'importe
s'il y a hFerme("") ou HAnnuleDéclaration pour la requête sur le poste
qui fait la modif dans le fichier (directement dans le fichier, pas à
travers la requête, qui est d'ailleurs pas la même que celle lu sur
l'autre poste, mais utilise les mêmes fichiers.)

Est-ce que l'éditeur de code ne traite pas toujours toutes les lignes de
code et quelques vieux bouts de code restent inchangés?


ted wrote:

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.

Non, pour rétablir la vitesse lié au mécanisme OpsLock, il faut que
tous les processus qui ont ouvert le fichier le referme. C'est ce que
j'ai constaté et ce que Microsoft docummente :

Alors là tu affirme que le problème vient des OpLocks? Donc il y a des
cas où HF utilise les OpLocks?

Je confirme que la fermêture des fenêtres, et même de l'application, ne
retablissent pas la vitesse d'origine. Le moment qu'un des postes
re-ouvre l'application et accède la même fenêtre en lecture seule ça va
normalement, mais un 2e utilisateur sera de nouveau rallenti.

Je précise que notre application ne ferme jamais exlicitement les
fichiers. Selon la doc de Windev, les fichiers sont géres
automatiquement. Si la fermeture explicite puisse aider, merci de m'en
informer. Les tests fait rapidement n'ont pas montré de différence.

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.

Et pourtant je le prouve. Je ne sais pas ce qui est utilisé dans
Hyper File. Mais ci-dessous je donne un code W-Langag qui utilise les
fonctions de base de l'API pour la gestions des fichiers. Ce code
permet de reproduire le phénomène. Ceux qui veulent le convertir dans
un autre lanage peuvent le faire, c'est sans rapport avec le langage.


Ce code permet au chois de faire une lecture sur un fichier ou de
faire un petit blocage sur un fichier. Pour utiliser ce code et
mettre le phénomène en évidence, il faut l'exécuter comme suit : -
Test mono-utilisation Sur un poste faire une lecture en étant seul
sur le fichier

- Test multi-utilisation Sur un poste faire un blocage d'un octet du
fichier Sur l'autre poste faire une lecture du même fichier.

Avec preuve du contraire je pensais p.ex. de prouver que les autres
gestions de base de données avec "file share" se comporte de la même
façon que Windev. Si c'était le cas on pourrait dire que c'est un
phénomène général.

Je regrette, je ne comprends pas le but de ta démo. Je n'ai pas
d'expérience en programmation proche d'un OS. Tout de même,

FILE_FLAG_OVERLAPPED est un entier=0x40000000
//traitement asynchrone de L/E

est déclaré, mais pas utilisé dans le code en question. Si j'ai compris
correctement la doc de Microsoft, l'usage de OpLocks ne devrait alors
pas être possible.

D'autre part

//Ouverture en L/E
eTypeOuverture=GENERIC_READ+GENERIC_WRITE

me surprend. Depuis longtemps je dis que les requêtes "en lecture seule"
ne se comporte pas comme des "requêtes en lecture seul".

Est-il stupide de demander pourquoi on devrait ouvrir les fichiers d'une
requête SELECT en lecture et écriture?

Comme j'ai dit, j'y comprends rien, ais j'aurais pensé qu'une ouverture
de fichier pour une requête sans paramètre hModifieFichier utiliserait
quelque chose comme:
eTypeOuverture = GENERIC_READ
eAttributsCache = FILE_ATTRIBUTE_READONLY + FILE_FLAG_RANDOM_ACCESS

Et si le code ne correspondait pas à l'ouverture des fichiers d'une
requête SELECT, utilisé p.ex. par Windev, alors quel est le but de ce
test, stp?

Salutations
Mat

mat <NoSpam-mnobs@bluemail.ch> écrivait news:41556b69_3@news.bluewin.ch:

Salut,

2) J'ai souvent compilé le projet et tout à coup il m'a donné un

Pas de rapport avec le sujet en cours.

Je précise que notre application ne ferme jamais exlicitement les
fichiers. Selon la doc de Windev, les fichiers sont géres
automatiquement. Si la fermeture explicite puisse aider, merci de m'en
informer. Les tests fait rapidement n'ont pas montré de différence.

Effectivement pour rétablir lee Opslocks il faudrait que tous les postes
ferme le/les fichiers sur lesqueles il y a eu modif ou blocage.

FILE_FLAG_OVERLAPPED est un entier=0x40000000
//traitement asynchrone de L/E

est déclaré, mais pas utilisé dans le code en question. Si j'ai
compris correctement la doc de Microsoft, l'usage de OpLocks ne
devrait alors pas être possible.

D'après ce que j'ai compris/testé dés que tu manipules un fichier sur un
serveur NT/2000, l'utilisation des OpsLocks est automatiquement faite par
le system.
Les quelques tests que j'ai fait avec FILE_FLAG_OVERLAPPED montre que ce
paramètre n'est pas utilisable si on veut lires des données à jour.
Je ne peux maintenant pas t'assurer que les paramètres de mon code sont
ceux utilisés par Hyperfile, mais ils permettent de reproduir le même
phénomène.
As-tu fait un test de ce code ? N'as tu pas constaté les mêmes
différences de performance qu'avec Hyperfile ?

D'autre part

//Ouverture en L/E
eTypeOuverture=GENERIC_READ+GENERIC_WRITE

me surprend. Depuis longtemps je dis que les requêtes "en lecture
seule" ne se comporte pas comme des "requêtes en lecture seul".

J'ai utilisé ces paramètre car dans mes appli en général je fit des
modif, et le pense que les requêtes ne re-ouvre pas les fichiers.
Maintenant tu peux mettre : eTypeOuverture=GENERIC_READ dans le cas de la
lecture (mais laisse eTypeOuverture=GENERIC_READ+GENERIC_WRITE pour le
lancement sur le poste qui bloque). A priori cela ne provoque pas de
différence.

Comme j'ai dit, j'y comprends rien, ais j'aurais pensé qu'une
ouverture de fichier pour une requête sans paramètre hModifieFichier
utiliserait quelque chose comme:
eTypeOuverture = GENERIC_READ
eAttributsCache = FILE_ATTRIBUTE_READONLY + FILE_FLAG_RANDOM_ACCESS

Et si le code ne correspondait pas à l'ouverture des fichiers d'une
requête SELECT, utilisé p.ex. par Windev, alors quel est le but de ce
test, stp?

Le but de ce test et de montrer que l'on peut obtenir ce même
ralentissement sans Hyperfile, avec quelques fonctions de base de l'API
de gestion des fichiers.
Si tu veux, tu peux faire des essais, et faire varier les différentes
constantes et différents paramètres. Si tu trouves une combinaison de
paramètres qui ne provoque pas de ralentissement dés qu'un second poste
fait des blocages/modif tient moi au courant, je contrete test et on fait
remonter à l'éditeur.


--
En esperant avancé toujours un peu plus.
ted

ted wrote:

Je précise que notre application ne ferme jamais exlicitement les
fichiers. Selon la doc de Windev, les fichiers sont géres
automatiquement. Si la fermeture explicite puisse aider, merci de m'en
informer. Les tests fait rapidement n'ont pas montré de différence.

Effectivement pour rétablir lee Opslocks il faudrait que tous les postes
ferme le/les fichiers sur lesqueles il y a eu modif ou blocage.

Manque de précision de ma part. Pour les tests, j'ai ajouté HFerme dans
toutes les fenêtres utilisés. Pourtant, la fermeture des fenêtres, ou
même de l'application, ne sont pas suffisants.

D'autre part

//Ouverture en L/E
eTypeOuverture=GENERIC_READ+GENERIC_WRITE

me surprend. Depuis longtemps je dis que les requêtes "en lecture
seule" ne se comporte pas comme des "requêtes en lecture seul".

J'ai utilisé ces paramètre car dans mes appli en général je fit des
modif, et le pense que les requêtes ne re-ouvre pas les fichiers.
Maintenant tu peux mettre : eTypeOuverture=GENERIC_READ dans le cas de la
lecture (mais laisse eTypeOuverture=GENERIC_READ+GENERIC_WRITE pour le
lancement sur le poste qui bloque). A priori cela ne provoque pas de
différence.

N'ayant pas d'expérience dans ce domaine, j'ai fait fausse route.

Revenant sur le principe de base: Pour autant que je sache, une requête
traditionelle exécuté sur un poste demande le fichier du serveur et
ensuite le traite en local. Ce type de conflit n'existe alors pas,
puisque la lecture est en local.

Le comportement décrit dans ton test correspond justement à quelque
chose que tu disait n'existait pas dans le cas d'une requête Windev sur
HF: l'usage d'un fichier sur le serveur.

J'espère que c'est plus précis et compréhensible cette fois.

Salutations
Mat

mat <NoSpam-mnobs@bluemail.ch> écrivait news:4157d719$1_1
@news.bluewin.ch:

Salut,

Je suis surpris de tes remarques qui me semblent beaucoup moins
judicieuses que les précédentes...

Revenant sur le principe de base: Pour autant que je sache, une requˆte
traditionelle ex‚cut‚ sur un poste demande le fichier du serveur et
ensuite le traite en local. Ce type de conflit n'existe alors pas,
puisque la lecture est en local.

J'espère bien que le fichier n'est pas récupéré en local sur le poste de
chaque client pour l'exécution de chaque requête !
Imagine une requête qui porte sur 3 fichiers, avec chacun 200.000
enregistrements. Avec cette technique il faudrait avoir des postes
clients avec +++ mémoire et +++ de place disque.
De plus durant le temps de 'copie' des fichiers en local des modif
pourraient être faites sur les fichiers...
Image aussi une requête dont le résultat est 1 enreg. Selon toi, dans ce
cas là aussi, il faudrait récupérer tout les fichiers en local ?

Le comportement d‚crit dans ton test correspond justement … quelque
chose que tu disait n'existait pas dans le cas d'une requˆte Windev sur
HF: l'usage d'un fichier sur le serveur.

Ce que j'ai décrit c'est l'utilisation d'un fichier partagé en réseau.
J'espère que Hyperfile utilise directements les données des fichiers en
réseau, et cela en même temps depuis les différents postes clients. Par
contre ce que je n'espère pas c'est que Hyperfile cré un fichier
temporaire sur le serveur durant l'exécution. Suite à ton poste, j'ai
d'ailleur demandé confirmation à l'éditeur qui m'a confirmé ne pas
utiliser de fichier temporaire sur le serveur (ni sur le poste local).

--
En esperant t'avoir aidé.
ted

ted wrote:

Revenant sur le principe de base: Pour autant que je sache, une requˆte
traditionelle ex‚cut‚ sur un poste demande le fichier du serveur et
ensuite le traite en local. Ce type de conflit n'existe alors pas,
puisque la lecture est en local.

J'espère bien que le fichier n'est pas récupéré en local sur le poste de
chaque client pour l'exécution de chaque requête !
Imagine une requête qui porte sur 3 fichiers, avec chacun 200.000
enregistrements. Avec cette technique il faudrait avoir des postes
clients avec +++ mémoire et +++ de place disque.
De plus durant le temps de 'copie' des fichiers en local des modif
pourraient être faites sur les fichiers...
Image aussi une requête dont le résultat est 1 enreg. Selon toi, dans ce
cas là aussi, il faudrait récupérer tout les fichiers en local ?

Bonjour Ted,

Il me semble que le seul but de tes posts est d'invalider mes
observations au lieu de les prendre pour ce qu'elles sont: des pistes
pour trouver la source du problème. Ce que tu dis ci-haut est n'importe
quoi.

Je n'ai aucune idée comment une requête fonctionne chez Visual Foxpro,
Access et Paradox, mais je sais qu'elles n'ont pas la lenteur des
requêtes de Windev sur HF après modifications de données. Je pense la
discussion a montré que vous êtes au courant de ces ralentissements et
n'avez pas de solution. Peut-être devriez vous ouvrir un peu l'esprit et
ne pas nier à priori les observations et l'expérience des autres?

Ci-bas un extrait de l'aide en ligne de Paradox 7 expliquant les
requêtes. Dans le cas de SQL server elles sont exécutés sur le serveur
et autrement en local. Si vous n'êtes pas au courant comment les
requêtes fonctionnent normalement avec un produit autre que Windev, je
ne peux rien pour vous.

Que tu trouves ça génial ou pas, les requêtes Paradox sont moyennement
bien plus vite que Windev sur HF, sans exécution en arrière plan. De la
situation après modification des fichiers des données on parle même pas.
Mais puisqu'on y est déjà: avec Paradox on peut également: définir le
nom du fichier temporaire contenant le résultat, définir le répertoire
où se trouve ce fichier, renommer le fichier par défaut "Answer.db" et
on a un fichier physique réutilisable, pour des listes, requêtes
enchaînées, archives, etc. Des choses dont un utilisateur Windev ne peut
que rêver pour l'instant. Et tout cela dans un temps époustouflant.

Pourtant, le but de mon post n'a jamais été pour dire qu'un produit est
mieux qu'un autre, mais que d'autres produits ne montrent pas ce
phénomène extrêmement gênant des requêtes Windev sur HF. C'est ma faute
si je ne sais pas m'exprimer mieux ou me suis laissé entraîner dans une
discussion apparemment inutile. Encore du temps perdu mais ce n'est pas
nouveau avec Windev et surtout PC Soft.

Salutations
Mat


AIDE EN LIGNE DE PARADOX 7
--------------------------
Queries Against Remote Tables
These options apply only to queries of remote data on SQL servers.
Running queries locally is slower, but might be necessary
for example, if you're querying joined tables from more than one server.

Query May Be Local Or Remote
Choose this button to make Paradox attempt to run the query remotely (as
described below). If this fails, Paradox runs the query locally (as
described below).

Run Query Remotely
Choose this button to make Paradox request that the server run the query
and send back only the answer data.

Run Query Locally
Choose this button to make Paradox run the query locally. This means
that Paradox

1. Requests all data in queried tables from the server.
2. Runs the query on your computer system.

"mat" <NoSpam-mnobs@bluemail.ch> a écrit dans le message de
news:41593cea_3@news.bluewin.ch...

Que tu trouves ça génial ou pas, les requêtes Paradox sont moyennement
bien plus vite que Windev sur HF, sans exécution en arrière plan. De la
situation après modification des fichiers des données on parle même pas.
Mais puisqu'on y est déjà: avec Paradox on peut également: définir le
nom du fichier temporaire contenant le résultat, définir le répertoire
où se trouve ce fichier, renommer le fichier par défaut "Answer.db" et
on a un fichier physique réutilisable, pour des listes, requêtes
enchaînées, archives, etc. Des choses dont un utilisateur Windev ne peut
que rêver pour l'instant. Et tout cela dans un temps époustouflant.

Bonjour Mat,

Malheureusement rien n'est parfait en ce bas monde. L'environnement de
développement Windev est fabuleux et exceptionnel, mais son talon d'Achille
est la vitesse des requêtes. Mais je garde espoir parce que je vois une
amélioration constante du produit.

Comme vétéran des produits FoxPro, je me rappelle que la première version
qui a intégré le SQL était tellement lente que j'ai revendu à rabais cette
version de FoxPro en moins d'une semaine. Mais cela n'a pas duré très
longtemps, à partir de la version suivante - la technologie Rushmore
aidant - tout était d'une vitesse fulgurante.

Comme tu dis, la création de fichiers temporaires physiques réutilisable par
un SQL est épatant. Pour travailler des requêtes complexes, il suffit de
décortiquer en plusieurs fichiers temporaires très facile à créer et à
manipuler. De plus, dès qu'on ferme un fichier temporaire, il s'efface
automatiquement du disque dur.

Je ferai face aux même problèmes que toi concernant la vitesse HF et des
requêtes d'ici quelques semaines. Heureusement, la version 9 est à l'horizon
avec sa vitesse C/S améliorée. Si je regarde l'évolution de Windev ces
dernières années, je fais le paris que PCS va éventuellement trouver
l'astuce qui va rejoindre les vitesses de FoxPro, Paradox et de ses
semblables. Entre-temps, je crois bien que la solution est de trouver des
astuces, jouer sur les (gros) index et placer des messages et des jauges
pour faire patienter le client.

Réal Philippon (Phil)