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.
Bref je m'explique:
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
chez moi sous un r=E9pertoire partag=E9 d'XP Pro et l=E0 m=EAme r=E9sultat :
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.
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 (enlever '-pas de spam' pour me joindre) http://www.albygest.com
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 spam.trepp@free.fr
(enlever '-pas de spam' pour me joindre)
http://www.albygest.com
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 (enlever '-pas de spam' pour me joindre) http://www.albygest.com
Vbig
Francis a pensé très fort :
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.
[...]
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 a pensé très fort :
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.
[...]
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 ^^)
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.
[...]
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 ^^)
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.
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.
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.
Francis
> 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 !
> 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.
> 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
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" a écrit dans le message de news:
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
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" <francis@coffrini.com> a écrit dans le message de news:
1156005245.382519.241650@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.
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" a écrit dans le message de news:
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
Le samedi 19 Août 2006 à 18:34 par 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. 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
J'ai rencontré ce même problème de lenteur d'application installée sur un 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'une 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 choisir 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 de réponses sont excellents.
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
J'ai rencontré ce même problème de lenteur d'application installée sur un 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'une 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 choisir 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 de réponses sont excellents.
