Lenteur fonctionnement en réseau appli Windev sous Samba Redhat

Discussion:

(trop ancien pour répondre)

Francis

2006-08-19 16:34:05 UTC

Pour augmenter les performances de mon système info, je viens
d'installer un serveur Dell pentium dual core 2.8Ghz 2Gb de RAM en SATA
(Raid 1) avec OS linux redhat Server entreprise ES 4.0 avec Samba pour
le serveur de fichier.

Tout ça pour faire fonctionner une appli Windev du commerce (dont je
tairai le nom) depuis 5 postes clients Windows XP.

Le souci c'est que malgré le passage à un serveur dédié plus
performant (anciennement c'était un simple répertoire partagé sous
XP), l'amélioration et notamment les temps d'accès aux diffèrents
menus ne sont pas au rendez vous.

Bref je m'explique:
Je me loge sous un user x et j'accède à tel menu : temps d'accès = 4
s (correct)
L'utilisateur x étant logé, je me loge sous un autre poste client
sous le user y et j'accède au même menu que le user x et la le temps
d'accès explose : 16 s (pas correct du tout).

Après sollicitation du service maintenance de l'appli Windev, on me
réponds que ça devrait pas le faire ... et c'est tout bref savent
pas.

Je copie l'intégralité des fichiers du serveur et j'essaye tout ça
chez moi sous un répertoire partagé d'XP Pro et là même résultat :
dès que plus d'un seul utilisateur est logé sous un des menu les
temps d'accès s'envolent.

A voir l'activité réseau sur ces accès il y a l'air d'y avoir pas
mal de traffic de fichiers, donc apparement pas de latences.

Alors je m'adresse aux spécialistes Windev ou Samba (à vous
lecteurs), si vous aviez une idée de ce qui est à l'origine des ces
lenteurs d'accès lorsqu'on passe à plus d'un utilisateurs ?

Je connais rien à Windev mais les fichiers sollicités semblent être
du type .dat et .ndx et la taille des fichiers correspondants aux menus
appelés font à peu près 3/4Mo.

pour la config Samba sous redHat, parametrage standard en mode security
avec accès restreint sous certains users, bref du basique qui
habituellement fonctionne bien.

MERCI D'AVANCE

Michel HERRSCHER

2006-08-19 19:14:07 UTC

Permalink

Post by Francis
Pour augmenter les performances de mon système info, je viens
d'installer un serveur Dell pentium dual core 2.8Ghz 2Gb de RAM en SATA
(Raid 1) avec OS linux redhat Server entreprise ES 4.0 avec Samba pour
le serveur de fichier.
Tout ça pour faire fonctionner une appli Windev du commerce (dont je
tairai le nom) depuis 5 postes clients Windows XP.
Le souci c'est que malgré le passage à un serveur dédié plus
performant (anciennement c'était un simple répertoire partagé sous
XP), l'amélioration et notamment les temps d'accès aux diffèrents
menus ne sont pas au rendez vous.
Je me loge sous un user x et j'accède à tel menu : temps d'accès = 4
s (correct)
L'utilisateur x étant logé, je me loge sous un autre poste client
sous le user y et j'accède au même menu que le user x et la le temps
d'accès explose : 16 s (pas correct du tout).
Après sollicitation du service maintenance de l'appli Windev, on me
réponds que ça devrait pas le faire ... et c'est tout bref savent
pas.
Je copie l'intégralité des fichiers du serveur et j'essaye tout ça
dès que plus d'un seul utilisateur est logé sous un des menu les
temps d'accès s'envolent.
A voir l'activité réseau sur ces accès il y a l'air d'y avoir pas
mal de traffic de fichiers, donc apparement pas de latences.
Alors je m'adresse aux spécialistes Windev ou Samba (à vous
lecteurs), si vous aviez une idée de ce qui est à l'origine des ces
lenteurs d'accès lorsqu'on passe à plus d'un utilisateurs ?
Je connais rien à Windev mais les fichiers sollicités semblent être
du type .dat et .ndx et la taille des fichiers correspondants aux menus
appelés font à peu près 3/4Mo.
pour la config Samba sous redHat, parametrage standard en mode security
avec accès restreint sous certains users, bref du basique qui
habituellement fonctionne bien.
MERCI D'AVANCE

Samba ou Windows ne sont probablement pas la cause.

Je pense que c'est plutôt dans l'application qu'il faut chercher

Plus de détails sur les fenetres, les accès constatés nous permettraient
plus de vous aider.

A+
Michel HERRSCHER CONSULTANT
Tel : +33450870912
http://www.mhc.herrscher.fr
Président WINDASSO - Association des utilisateurs WxxDEV(c)
http://www.windasso.org

nwjb

2006-08-20 09:12:06 UTC

Permalink

Voir peut être le paramètre oplocks dans samba.
Nous utilisons en général oplocks=false.

--
J.Bratières

Enlever paspub pour répondre
Please remove paspub when answering

Francis

2006-08-20 11:07:25 UTC

Permalink

J'ai effectivement constaté que certains paramètres étaient à
intégrer dans le smb.conf.

Je vais essayer ça demain, le oplocks = no

Ainsi que les paramètres suivants (trouvés dans un forum) conseillé
pour l'exploitation de HyperFile

[global]
locking = yes
strict locking = yes
share modes = yes
oplocks = no
kernel oplocks = no
blocking locks = no
fake oplocks = no
level2 oplocks = no

Pour les détails de l'applis notamment dans les menus, je ne veux pas
trop rentrer dans le détails, car je ne souhaite pas nommer le
programme. Il s'agit simplement d'un banal planning, qui à mon avis
sous Acces est instantanné ...

J'ai quelques élèments de réponses vu dans les forums et qui font
mention de lenteurs avec l'Hyperfile de Windev, notamment en réseau
lorsqu'un deuxieme utilisateurs est connecté. Certains ont pu
quantifier ces ralentissements jusqu'a + de 270% en mode multi
utilisateur.

En fait ce problème semble connu (?) mais les principaux concernés
(sauf les utilisateurs) semblent aussi ignorer le problème et mettent
en cause les insuffisances de performances du réseau et des machines.

Je vais donc voir si la modid de la config du smb.conf change quelque
chose, si rien ne change je ferais les essais sur un gros serveur sous
2003 Server pour ne plus mettre en cause le réseau et les machines.

Mais bon à mon avis je penche pour une faiblesse (bug ?) de
l'HyperFile.

[Bernard Vessiot]

2006-08-20 11:43:55 UTC

Permalink

Post by Francis
J'ai effectivement constaté que certains paramètres étaient à
intégrer dans le smb.conf.
Je vais essayer ça demain, le oplocks = no
Ainsi que les paramètres suivants (trouvés dans un forum) conseillé
pour l'exploitation de HyperFile
[global]
locking = yes
strict locking = yes
share modes = yes
oplocks = no
kernel oplocks = no
blocking locks = no
fake oplocks = no
level2 oplocks = no
Pour les détails de l'applis notamment dans les menus, je ne veux pas
trop rentrer dans le détails, car je ne souhaite pas nommer le
programme. Il s'agit simplement d'un banal planning, qui à mon avis
sous Acces est instantanné ...
J'ai quelques élèments de réponses vu dans les forums et qui font
mention de lenteurs avec l'Hyperfile de Windev, notamment en réseau
lorsqu'un deuxieme utilisateurs est connecté. Certains ont pu
quantifier ces ralentissements jusqu'a + de 270% en mode multi
utilisateur.
En fait ce problème semble connu (?) mais les principaux concernés
(sauf les utilisateurs) semblent aussi ignorer le problème et mettent
en cause les insuffisances de performances du réseau et des machines.
Je vais donc voir si la modid de la config du smb.conf change quelque
chose, si rien ne change je ferais les essais sur un gros serveur sous
2003 Server pour ne plus mettre en cause le réseau et les machines.
Mais bon à mon avis je penche pour une faiblesse (bug ?) de
l'HyperFile.

bonjour,
ce qui est curieux quand meme, c'est que d'apres tes dires, avant sur
un simple répertoire partagé sous Xp pro cela fonctionait bien , non ?
Au fait connais tu la version d'hyperfile ?
@+++

--
[Bernard Vessiot]
34980 Saint Gély du Fesc

mat

2006-08-20 12:25:15 UTC

Permalink

Bonjour,

comme Michel, je ne pense pas que le problème vient de Samba ou du
matériel. Lors de mes essais avec des fichiers HF sur serveur Linux
(Debian/Ubuntu) j'ai trouvé que le comportement sous Samba était le même
que sous Windows 2000 Serveur, y compris problème Oplocks. Les temps
d'accès étaient comparables, la seul différence étant que le serveur
Linux était un PIII/500Mhz/512MB RAM et W2K serveur sur une machine
P4/2GHz/512MB RAM.

Le problème décrit en réseau est typique pour les versions Windev/HF
7/7.5/8. Avec la version 9, on ne remarque plus ce phénomène dû
probablement au type d'accès fichier choisi auparavant par PC Soft, car
inconnu avec des produits comparables d'autres éditeurs.

Salutations
Mat

Gilles TOURREAU

2006-08-20 12:23:55 UTC

Permalink

Pour bien utiliser HyperFile en réseau Windows :

http://www.pcsoft.fr/st/telec/windev7/tableaux/HyperFileSurServeurWindows.pdf

--
Gilles TOURREAU
Responsable informatique
***@pos.fr

Société P.O.S
Spécialiste en motoculture depuis + de 30 ans !
http://www.pos.fr

mat

2006-08-20 13:35:33 UTC

Permalink

Gilles TOURREAU wrote:
...

Post by Gilles TOURREAU
http://www.pcsoft.fr/st/telec/windev7/tableaux/HyperFileSurServeurWindows.pdf

Bonjour Gilles,

avec tous mes respects pour tes connaissances de Windev et assistance
aux utilisateurs: ce document est une insolence de la part de PC Soft et
un insulte de leur clients. Sachant que les problèmes décrits à l'époque
(2003) était dûs à des failles de Hyper File, PC Soft accusent Windows
et la mauvaise programmation de leur clients. Il y a suffisamment de
preuves que cela n'est pas vrai, la plus simple étant que les problèmes
ont disparu depuis. J'ai publié des tests comparatifs à ce sujet en 2003
et 2004. Ce comportement de PC Soft nous a fait perdre un temps fou,
cherchant l'erreur pendant plus d'une année chez nous et quand nous
étions certain du vrai coupable (HF), pour modifier les accès fichier
afin d'obtenir des temps de réponse plus ou moins corrects.

Salutations
Mat

Gilles TOURREAU

2006-08-20 14:03:12 UTC

Permalink

Post by mat
...

Post by Gilles TOURREAU
http://www.pcsoft.fr/st/telec/windev7/tableaux/HyperFileSurServeurWindows.pdf

Bonjour Gilles,
avec tous mes respects pour tes connaissances de Windev et assistance aux
utilisateurs: ce document est une insolence de la part de PC Soft et un
insulte de leur clients. Sachant que les problèmes décrits à l'époque (2003)
était dûs à des failles de Hyper File, PC Soft accusent Windows et la
mauvaise programmation de leur clients. Il y a suffisamment de preuves que
cela n'est pas vrai, la plus simple étant que les problèmes ont disparu
depuis. J'ai publié des tests comparatifs à ce sujet en 2003 et 2004. Ce
comportement de PC Soft nous a fait perdre un temps fou, cherchant l'erreur
pendant plus d'une année chez nous et quand nous étions certain du vrai
coupable (HF), pour modifier les accès fichier afin d'obtenir des temps de
réponse plus ou moins corrects.
Salutations
Mat

C'était juste un article que j'avais lu à l'époque...

Personnellement je n'ai jamais eu de problème de rapidité en réseau
avec HF depuis Windev 7.5, donc je ne suis pas spécialiste de ce genre
de problème.

Il y a eu une fois, où j'ai eu des ralentissement, c'était sur un
serveur Windows 2000, mais cela vennait d'un problème de droit au
niveau du serveur...

On pourrait avoir l'adresse des tests que tu as réalisé, ou sont-ils
privées à ton entreprise ?

Cordialement

--
Gilles TOURREAU
Responsable informatique
***@pos.fr

Société P.O.S
Spécialiste en motoculture depuis + de 30 ans !
http://www.pos.fr

Francis

2006-08-20 15:15:58 UTC

Permalink

Pour repondre à la question de Bernard:
Non que ce soit sous Linux ou répertoire partagé Xp Pro, le
problème reste le même.

Pour Mat, merci pour ton travail objectif (infos et tests) que j'ai pu
trouver sur divers forum qui mettent bien en évidence que le problème
est certainement dû à un soucis d'hyperfile.

Je pense que c'est le même problème que j'observe à ce jour chez ce
client qui exploite l'appli Windev.
Au passage, je ne connais pas les versions de Windev ou Hyperfile
ayants servis à l'ecriture et à la compil de l'appli, tout ce que je
sais c'est qu'il utilise la toute dernière édition de l'appli qui
date de 2006.

Alors je me pose les questions suivantes:
- est que ce problème a été pris en compte et a été réglé par
PCSoft depuis 2004/2005 ?
- Si oui, on peut donc en déduire que ce soucis de multiutilisateurs a
été réglé ?
- Vu que le client utilise cette appli depuis 2001 est-ce que les mises
à jours effectuées ont correctement mises en place et que pour des
questions de compatibilités des données de la base hyperfile (au fil
des versions), certains modules tel que l'hyperfile n'aurait pu être
mis à jour ?

Si je me permets de vous solliciter, c'est pour pouvoir appeller
l'éditeur avec des élèments solides afin de résoudre ce problème
et d'éviter de m'attendre dire que c'est le matériel qui est en cause
!

Merci en tout cas pour votre aide.

mat

2006-08-20 17:01:23 UTC

Permalink

Francis wrote:
...

Post by Francis
- est que ce problème a été pris en compte et a été réglé par
PCSoft depuis 2004/2005 ?

officiellement non, car il n'y a jamais eu de problème!

Post by Francis
- Si oui, on peut donc en déduire que ce soucis de multiutilisateurs a
été réglé ?

en réalité, oui. Je ne me rappelle plus si avec les dernières
sous-versions de WD8, mais certainement avec WD9.

Post by Francis
- Vu que le client utilise cette appli depuis 2001 est-ce que les mises
à jours effectuées ont correctement mises en place et que pour des
questions de compatibilités des données de la base hyperfile (au fil
des versions), certains modules tel que l'hyperfile n'aurait pu être
mis à jour ?

chez PC Soft, aucune mise à jour d'une version de Windev antérieure à la
courante

Post by Francis
Si je me permets de vous solliciter, c'est pour pouvoir appeller
l'éditeur avec des élèments solides afin de résoudre ce problème
et d'éviter de m'attendre dire que c'est le matériel qui est en cause
!

bonne chance!

jacques trepp

2006-08-21 07:35:16 UTC

Permalink

Post by mat
...

Post by Gilles TOURREAU
http://www.pcsoft.fr/st/telec/windev7/tableaux/HyperFileSurServeurWindows.pdf

Bonjour Gilles,
avec tous mes respects pour tes connaissances de Windev et assistance
aux utilisateurs: ce document est une insolence de la part de PC Soft et
un insulte de leur clients. /...

bonjour à tous.
Je reconnais qu'à la lecture du document, j'ai enfin compris :
ça n'est pas trop lent en multi utilisateurs ... c'est simplement trop
rapide en mono utilisateur.
Sots que nous sommes ;)

--
Jacques Trepp
Albygest - 81160 - St Juery
jacques-pas de ***@free.fr
(enlever '-pas de spam' pour me joindre)
http://www.albygest.com

Francis

2006-08-21 10:10:22 UTC

Permalink

http://www.pcsoft.fr/st/telec/windev7/tableaux/HyperFileSurServeurWindows.pdf

C'est vrai qu'a lecture de ce document on se demande si on ne se moque
pas du monde ... mais bon il date de 2003. Les choses ont bien
changées.

Par contre d'après ce que j'en ai lu, ca marcherait mieux sous
Linux/Unix que sous Windows...

Bon j'arrête c'est vrai que les choses ont bien changé depuis Windev
9.

J'ai donc testé le oplocks= no dans le smb.conf et rien ne s'arrange
bien au contraire, la temps monoutilisateur qui était de 4s passe à
16s et en multiutilisateurs on reste à 16s.
On perds donc le gain en monoutilisateur, ou bien comme dit le
collègue du message ci-dessus "ce n'est pas qu'il est lent, c'est
qu'il est trop rapide en monoutilisateur".

J'ai aussi testé les autres paramètres dans le smb.conf (voir sur le
message précédent) et pareil, je perds les 4s du mode
monoutilisateur.

On laisse donc tomber le matériel et son OS, je doute que 2003 TSE
arrange d'ailleurs les choses et de toutes façon le client n'est pas
prêt à investir des sous pour un simple partage de fichier et ça se
comprends.

En fait, la solution c'est l'éditeur de l'appli développée qui la
tient et je remercie encore Mat pour avoir maintenu et défendu le fait
que c'est hyperfile qui est à l'origine de ces ralentissements.
Et comme la balle est chez l'éditeur et qu'effectivement cette appli a
été developpée et compilée sous Windev 5.5 (sic!).
Et comme l'editeur est un éditeur responsable (ca se fait rare), il va
nous recompiler l'appli sous Windev 10 et nous la renvoyer pour qu'on
la teste.

Voilà on attends plus que de la recevoir pour vous faire part du
changement que j'espère positif.

Vbig

2006-08-21 07:58:27 UTC

Permalink

[...]

Comme l'ont correctement dit les autres, c'est la gestion en
multi-utilisateur avec couche OS / réseau / WinDev qui est à mettre en
cause dans le ralentissement de l'application.

Sans tout changer, la machine que vous décrivez suffit largement a
faire tourner un wiwdows serveur 2003 TSE / 5 Client windows XP

Donc si l'aplication que vous utilisez est compatible(*) avec une
utilisation en TSE. Faites les test, vous ne constaterez plus de
ralentissement a la connection du 2 eme utilisateurs (Plus de gestion
de réseau par windows, que de l'execution en local, le bonheur ^^)

Cordialement.

Francis

2006-08-21 10:20:47 UTC

Permalink

Post by Vbig
Donc si l'aplication que vous utilisez est compatible(*) avec une
utilisation en TSE. Faites les test, vous ne constaterez plus de
ralentissement a la connection du 2 eme utilisateurs (Plus de gestion
de réseau par windows, que de l'execution en local, le bonheur ^^)

Je m'excuse, mais je n'avais pas saisi le principe, c'est vrai que
d'utiliser des clients legers et d'utiliser grâce eux l'appli en local
résoudrait le pb.
Mais, c'est en dernier recours, et je souhaite le faire avec des
logiciels libre type Linux, donc conserver mon serveur sous OS
Linux/Samba. Pour ce qui est de comment mettre tout ça en place je ne
me suis pas encore posé la question.

Merci en tous cas pour vos réponses !

Fredo MT

2006-08-21 16:08:03 UTC

Permalink

Bonjour Francis,

Ce phénomène que tu décris je l'avais rencontré avec de l'Hyper File 5, le
seul moyen que j'avais trouvé pour éviter ces temps d'attente astronomique
était de gérer l'accès aux fichiers à la main (gestion des fermertures des
fichiers manuellement lors des accès... bref le gros bordel). Depuis ce
temps là, j'ai décidé d'utiliser un autre système de base de données
(SQLServer pour ne pas le nommer). La base de données est un métier à part
entière et je n'utilise plus du tout l'hyperFile si ce n'est que pour des
petites applications. La migration d'un projet sous un autre système de base
de données est un long travail, mais avec du recul je pense qu'il est
préférable de le faire et ne pas se trainer de l'HyperFile. C'est un gain de
temps incroyable après coût, mais bon tant qu'on ne l'a pas fait, on ne s'en
rend pas compte. Pour ce qui est du fournisseur de l'application, je pense
réellement que les développeurs n'ont pas optimisé l'accès aux fichiers
HyperFile et n'ont pas fait les tests nécessaires pour avoir des accès
réseaux convenables, le problème est surmontable...

"Francis" <***@coffrini.com> a écrit dans le message de news:
***@m73g2000cwd.googlegroups.com...
Pour augmenter les performances de mon système info, je viens
d'installer un serveur Dell pentium dual core 2.8Ghz 2Gb de RAM en SATA
(Raid 1) avec OS linux redhat Server entreprise ES 4.0 avec Samba pour
le serveur de fichier.

Tout ça pour faire fonctionner une appli Windev du commerce (dont je
tairai le nom) depuis 5 postes clients Windows XP.

Le souci c'est que malgré le passage à un serveur dédié plus
performant (anciennement c'était un simple répertoire partagé sous
XP), l'amélioration et notamment les temps d'accès aux diffèrents
menus ne sont pas au rendez vous.

Bref je m'explique:
Je me loge sous un user x et j'accède à tel menu : temps d'accès = 4
s (correct)
L'utilisateur x étant logé, je me loge sous un autre poste client
sous le user y et j'accède au même menu que le user x et la le temps
d'accès explose : 16 s (pas correct du tout).

Après sollicitation du service maintenance de l'appli Windev, on me
réponds que ça devrait pas le faire ... et c'est tout bref savent
pas.

Je copie l'intégralité des fichiers du serveur et j'essaye tout ça
chez moi sous un répertoire partagé d'XP Pro et là même résultat :
dès que plus d'un seul utilisateur est logé sous un des menu les
temps d'accès s'envolent.

A voir l'activité réseau sur ces accès il y a l'air d'y avoir pas
mal de traffic de fichiers, donc apparement pas de latences.

Alors je m'adresse aux spécialistes Windev ou Samba (à vous
lecteurs), si vous aviez une idée de ce qui est à l'origine des ces
lenteurs d'accès lorsqu'on passe à plus d'un utilisateurs ?

Je connais rien à Windev mais les fichiers sollicités semblent être
du type .dat et .ndx et la taille des fichiers correspondants aux menus
appelés font à peu près 3/4Mo.

pour la config Samba sous redHat, parametrage standard en mode security
avec accès restreint sous certains users, bref du basique qui
habituellement fonctionne bien.

MERCI D'AVANCE

jeanluc57

2019-06-05 12:49:27 UTC

Permalink

Pour augmenter les performances de mon syst=E8me info, je viens
d'installer un serveur Dell pentium dual core 2.8Ghz 2Gb de RAM en SATA
(Raid 1) avec OS linux redhat Server entreprise ES 4.0 avec Samba pour
le serveur de fichier.
Tout =E7a pour faire fonctionner une appli Windev du commerce (dont je
tairai le nom) depuis 5 postes clients Windows XP.
Le souci c'est que malgr=E9 le passage =E0 un serveur d=E9di=E9 plus
performant (anciennement c'=E9tait un simple r=E9pertoire partag=E9 sous
XP), l'am=E9lioration et notamment les temps d'acc=E8s aux diff=E8rents
menus ne sont pas au rendez vous.
Je me loge sous un user x et j'acc=E8de =E0 tel menu : temps d'acc=E8s =3D 4
s (correct)
L'utilisateur x =E9tant log=E9, je me loge sous un autre poste client
sous le user y et j'acc=E8de au m=EAme menu que le user x et la le temps
d'acc=E8s explose : 16 s (pas correct du tout).
Apr=E8s sollicitation du service maintenance de l'appli Windev, on me
r=E9ponds que =E7a devrait pas le faire ... et c'est tout bref savent
pas.
Je copie l'int=E9gralit=E9 des fichiers du serveur et j'essaye tout =E7a
d=E8s que plus d'un seul utilisateur est log=E9 sous un des menu les
temps d'acc=E8s s'envolent.
A voir l'activit=E9 r=E9seau sur ces acc=E8s il y a l'air d'y avoir pas
mal de traffic de fichiers, donc apparement pas de latences.
Alors je m'adresse aux sp=E9cialistes Windev ou Samba (=E0 vous
lecteurs), si vous aviez une id=E9e de ce qui est =E0 l'origine des ces
lenteurs d'acc=E8s lorsqu'on passe =E0 plus d'un utilisateurs ?
Je connais rien =E0 Windev mais les fichiers sollicit=E9s semblent =EAtre
du type .dat et .ndx et la taille des fichiers correspondants aux menus
appel=E9s font =E0 peu pr=E8s 3/4Mo.
pour la config Samba sous redHat, parametrage standard en mode security
avec acc=E8s restreint sous certains users, bref du basique qui
habituellement fonctionne bien.
MERCI D'AVANCE

J'ai rencontré ce même problème de lenteur d'application installée sur u
partage réseau :
Lenteur dès connexion du 2ème utilisateur.
Dans mon cas je me suis rendu compte que le problème survient lorsqu'un
application utilise une tablée liée à un fichier hyperfile.

Ma solution a été de défaire les liaisons :
Clic droit sur la table/ description de la table,
pour chacun des champs de la table aller dans l'onglet liaison et choisi
Aucun.

Puis programmer le remplissage de la table par exemple par une requête.

Le contenu de la table n'accédant plus directement au fichier les temps d
réponses sont excellents.