Lenteur FCO-Construction et Générateur de Rapport

[Isa]

Bonjour,

Nous avons un gros problème de lenteur des modules FCO-Construction et Générateur de rapport.

Ils sont installés sur chacun des postes de travail, ainsi que sur le serveur, et la base de donné est installée sur le serveur.

La mémoire de chaque poste de travail et du serveur a été up-gradée est suffisante (à notre connaissance, mais pouvez-vous me confirmer le minimum requis, ou l'optimal, je revérifierais par acquis de conscience...).

Notre anti-virus est NOD 32 et à la suggestion des techniciens de Forsum, nous avons exclus les fichers CDX, DBF, FDW et FIW, du scan, mais ça n'améliore pas de façon significative.

Et quand je dis que c'est lent, je veux dire TRÈS, TRÈS LENT: Facturer un projet ou il y a 50 TEC et plus peut prendre facilement 15 minutes. Et faire un rapport avec la générateur de rapport peut prendre facilement 2 à 3 minutes ou plus... si on mets pas trop de filtres. Si on éteint l'anti-virus, ça aide un peu, mais ça peut encore prendre plusieurs minutes pour sortir un rapport.

Avez-vous des pistes de solutions pour moi?

Merci de vos éventuelles réponses.

Isa

[MichelLabbe]

Salut Isa, j'ai un similaire de problème,Lenteur lenteur, erreur erreur....
La base de donnée est sur un serveur XP pro, avec 2 Gig mémoire vive,
un Disque dur 100 Gig IDE 7200 t/min, un processeur 2.4 GHz

Le tech m'a dit aussi d'exclure de l'antivirus les fichiers CDX, DBF, FDW et FIW.

Désactiver le parefeu ?? rien de changer encore lent,
Désactiver le scrennsaver, la mise en veille du disque dur.

Rien de changer Lent et lent.

La il me dit de mettre de même système d'exploitation Windows,
XP pro, Familliale, Vista serait incompatible ,donc chaque poste de travail devrait être sous le meme système d'exploitation. Mais pourtant le serveur est XP Pro, et l'autre poste de travail est sous XP Pro.

la je commence a me questionner...

Pourtant ce n'est qu'une database, échange de donné, car pour les transferts de document simple jusqu'à 200 megs (tester), le transfert se fait très rapidement.

[Thib]

bonjour à vous deux,

Nous avons eu le même problème avec le module LSG. Lenteur extrême même avec des PC très à jour.

Je suis désoler pour vous, mais je n'ai jamais réussi à trouver le problème.

Bonne chance!

Lartis à peut être une solution pour vous

[Lartis]

Bonjour,

Dernièrement, j'ai eu un problème bizarre avec LSG. J'ai carrément du le déinstaller chez un client pour pouvoir faire la mise à jour à la dernière version.

Thib: si tu déactive LSG, as-tu encore des problèmes de lenteur? (Menu Fichier - Configuration du système - Configuration AcoXternal, décoche tout et fait appliquer. )

Isa: Est-ce que "FCO Construction" est présent dans la configuration AcoXternal? Si oui, essai aussi de le décocher pour voir si ça corrige le problème. En faisant ça, tu déactives FCO Construction... donc on ne peut pas vraiment dire que ça corrige le problème.

[Thib]

Bonjour Lartis,

Merci de ton aide... mais nous avons laisser tomber le LSG pour fortune 1000 services professionnels.

sa doit faire au moins 2 ans que nous avons laisser tomber LSG

et pour répondre a ta question, je n'ai plus de problème de lenteur depuis que nous l'avons désinstallé.



Bonne journée

[Isa]

Bonjour Lartis,

J'ai décoché FCO-Construction de ACOXTERNAL. Tu ma dis que ça le désactiverait, pourtant je peux encore l'ouvrir, aller dans mes dossier et ouvrire de nouvelles factures. Mais ça ne semble pas avoir réglé le problème: seulement cocher les transactions que je désire facturer a pris un temps fou, j'ai du l'arrêter par le gestionnaire des tâches.

Bien triste de ne pas avoir de réponse à ce problème, car il est majeur et rend le système peu fonctionnel.

Si vous avez d'autres suggestions, ne vous gênez pas.

Merci

isa

[Lartis]

Bonjour Isa,

Il serait toujours possible de faire d'autres tests pour essayer de cibler d'où provient la lenteur.

Est-ce que tout le système (ordinateur) est lent? Est-ce Acomba au complet? Ou si c'est vraiment uniquement dans FCO-Construction?

As-tu une grosse base de données dans F1000.DTA? (grosseur du répertoire plus de 750Mo)

Est-ce que ta base de données est en réseau, sur un serveur? Si oui, essai de rouler Acomba directement sur le serveur pour voir si ça améliore les choses. Ça devrait être beaucoup plus rapide.

Tu pourrais essayer de défragmenter le répertoire F1000.DTA, ça peut aider.

As-tu la version la plus récente? Il y a des mise à jour d'ODBC et peut-être aussi de SDK entre la 9.10, la 9.12 et la 9.14. Je crois avoir constaté une amélioration de performance d'ODBC avec la version 9.14.

Sinon, après tout ça si c'est toujours non fonctionnel, je pourrais essayer de me connecter en remote et voir si je peux trouver d'où vient le problème. Si ça t'intéresse, tu peux trouver mes coordonnes mon site web.

Bonne chance!

[Lartis]

Bonjour,

J'ai constaté qu'une de mes recommandation n'était pas claire.

Lorsque je dis "rouler à partir du serveur", je veux dire se loguer sur le serveur pour que tout se fasse en local. (que rien ne dépende de la vitesse du réseau)

Si vous exécuter Acomba sur le serveur par l'intermédiaire du réseau, ça ne changera rien.

Désactiver (temporairement) l'antivirus peut aussi aider à cibler le problème. Si ça améliore la situation, c'est que le problème provient de la.

Au plaisir!

[Isa]

Bonjour Lartis,

Merci pour tes pistes, on va peut-être pouvoir régler ce problème.

Voici quelques réponses à tes questions:

Nous fonctionnons avec la version 9.14;

Nous sommes en réseau et F1000.dta est sur le serveur, son format est de 4.11GB;

Ce n'est que FCO-Construction et Générateur de rapport qui sont lents, Acomba et le reste de nos ordis ont une vitesse très fonctionnelle;

Je viens de faire un essai de FCO sur le serveur et WOW!!! C'est très rapide! Tout est plus rapide: ouvrir les fenêtres, ouvrir une nouvelle facture, cocher des transactions (5 secondes sur le serveur, et plus de 30 secondes sur mon poste de travail....), etc. Ça serait génial si ça pouvait être rapide comme ça sur tous les postes de travail!

Je viens de refaire le même test en désactivant l'anti-virus sur le serveur et sur mon poste: même résultat.

Ça me semble un problème de réseau, non? Avez-vous des pistes de solutions pour moi?

En attendant, je vais faire défragmenter F1000.dta sur le serveur, au cas ou ça aiderait.

Merci!

Isa

[Lartis]

Bonjour Isa,

Un répertoire d'entreprise de 4Go, c'est très gros. Mon impression, c'est que FCO-Construction transfert beaucoup de données du serveur vers l'ordi local. Comme cette information doit transiger par le réseau, c'est lent.

Le défrag peut aider un peu, mais ça me surprendrait que ça fasse une différence majeure.

Une solution pourrait être d'upgrader le réseau vers une technologie plus rapide. Par exemple, la très grosse majorité des réseaux sont actuellement en 100Mbits. C'est le plus standard, mais il existe mieux, les réseaux Gibabit (1000Mbits). Tous les transferts sur le reseau seraient 10 fois plus rapide, et la différence serait à coup sur majeure dans votre cas.

Si votre réseau est relativement petit, ça peut être abordable, mais le coût devient important s'il y a beaucoup d'ordinateur puisqu'il faut upgrader toutes les cartes réseaux vers des cartes qui supportent 1000Mbits.

Parlez-en à votre gestionnaire de réseau. Il serait possible de ne changer que certains postes et les routers/hub.

Bonne journée,

[Isa]

Bonjour Lartis,

Suite à tes suggestions, j'ai fais suivre une cure d'amaigrissement à F1000.dta sur serveur: il est descendu à 866MB. C'est assez petit, je crois... Pourtant le même problèem persiste. Même chose si je désactive encore les antivirus sur mon poste et le serveur.

Il ne me reste qu'à essayer de défragmenter le F1000.dta sur serveur, mais je n'ai pas grand espoir, car le problème de lenteur est depuis le début.

Je vais donc communiquer avec mon gestionnaire de réseau. Si vous avez d'autres suggestions, elles sont bienvenues.

Merci!

Isa

[Lartis]

Bonjour,

Petite précision par rapport au ménage du répertoire F1000.DTA. Le fait d'y enlever des entreprises, ou d'enlever des rapports, ne changera rien au problème. Pour être précis, c'est probablement les fichiers F1000.DTA\entreprise\CLgnFact.FDW et CFacture.FDW qui sont trop volumineux.

Ces fichiers contiennent les entêtes et lignes de factures, et ne peuvent pas être "nettoyé". (à moins de créer une nouvelle entreprise vide, et d'importer par exemple seulement les factures des 2 dernières années, mais ce n'est pas une travail simple à faire)

Par curiosité, quels grosseurs ont ces deux fichiers dans votre cas?

[Isa]

Bonjour Lartis,

J'ai CLgnfact FDW à 24,4MB
CLgnfact FIW à 15,4MB
Cfacture FDW à 10,7mb
et Cfacture FIW à 8.59MB



Est-ce trop gros?

Isa

[Lartis]

Non, en fait, c'est plutôt petit.

L'un de mes clients à un fichier CLgnfact FDW de 360Mo, plus de 10 fois plus gros que le vôtre.

Pourtant, puisque le problème n'existe pas si vous exécuter directement à partir du serveur, ça doit vouloir dire que votre réseau est la cause du problème.

À moins que le serveur soit vraiment beaucoup plus performant que votre station... Petit test intéressant, copier manuellement le répertoire F1000.DTA vers votre station et ouvrer localement sur la station pour voir si votre problème est vraiment réglé. Si le problème provient vraiment du réseau, ça devrait être beaucoup plus rapide. Si c'est encore lent, le problème provient peut-être d'un problème sur votre station.

Quoi que, encore la, si toutes les stations ont le même problème et pas le serveur, ça amène à penser que le problème est au niveau du réseau.

Faites-bien attention en faisant la copie locale. Personne ne doit avoir Acomba ouvert pendant la copie, et ne faites bien sur aucune modification sur le Acomba local, car ces changements seront perdus. Je vous conseille aussi d'effacer ce répertoire F1000.DTA local tout de suite après vos tests, pour éviter la confusion.

Bonne chance!

[Isa]

Bonjour Lartis,

J'ai copier F1000.dta du serveur sur le C de mon poste: Oui, ça marche! et pas mal bien à part ça.

Ça semble donc confirmer l'hypothèse que le problème se situe au niveau du réseau. Au moins maintenant c'est plus clair.

Je vais donc en parler avec mon gestionnaire de réseau.

Toujours ouverte à d'autres solutions si elles existent. Je vous tiendrai au courant des développements, et si le problème se résoud.

Merci!

Isa

[Isa]

Bonjour,

Voici un petit suivi sur la lenteur de FCO et du générateur de rapport: Il semblerait que le réseau soit, en partie, en cause. En effet, la transition n'est pas complété, mais des tests nous ont permis de voir qu'en mettant une switch de 1GB, la vitesse du générateur de rapport s'améliore dramatiquement, à la condition que le filage soit approprié.

En effet, il semblerait qu'il existe du filage de qualité supérieure pour fonctionner à 1GB... et les tests que nous avons fait vont dans ce sens.

En ce qui concerne FCO, mon gestionnaire de réseau soupçonne qu'il pourrait y avoir un problème dans la programmation: il crois que la réindexation se fait a chaque ''record'' (transaction) au lieu se faire à la fin du ''replace'' (cochage des transactions). Pouvez-vous me confirmer cela? J'ai aussi envoyer cette question dans les suggestion de Fortune 1000.

Je vous réécrirai dès que j'aurai plus de détails.

Isa

[Mpoirier]

j'ai poster aussi pour un probleme semblable mais avec une base de donner plus petite (- de 500 meg)

nous (compagnie informatique pour qui je travaille) avons plusieur client qui utilise acomba pour divers chose (facturation et paye principalement).

le hic avec le 1 Gig, ces que j'ai certain client qui sont dans 2 lieu geographique different (AfA : a plus de 30 min de l,un de l,autre) alors je ne peut calber partout le 1 Gig.

nous avons peut etre trouver une solution viable et correct, mias de plus ample test sont a faire avant de le mettre en place chez nos client

si vous vouler aider. rechercher OpLock de windows. si on de-active cela. on aurais plus de probleme

pour appuyer mes dire : notre nouveau client fonctionnais avec des vieux P2 et P3 SOUS linux. au niveau de la facturation il n'ont jamais eu de probleme ou meme ralentissement. et on parle d'une compagnie de plus de 10 ans vieux. 1 seul dossier de F1000.dat (il ne re-cree pas la meme compagnie a toute les ans). on a installer windows server 2003, migrer les donner et la lenteur s,est fait immediatement sentir. La seul chose que linux fait que windows ne fait pas ces le OpLock que windows gere pas mal. mais on a aucun control dessus. si on parvien a le mettre hors service on pourais alors tester.

le seul hic ces que il pourais y avoir corruption de donner. mais sous linux il en ont jamais eu. alors pourquoi il en aurais sous windows.

bon aller ce n'est qu'une piste. mais elle serait a explorer dans la mesure ou on ne peut pas faire le 1 Gig

[Lartis]

Bonjour,

Je viens de trouver quelque chose qui devrait vous intéresser, mais que je ne peux pas tester moi même:

The simplest way to resolve problems related to oplocks is to
disable them on behalf of the LAN Manager server.
This is done by manipulating the following registry key:
\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
EnableOplocks REG_DWORD 0 or 1
Default: 1 (true)
Specifies whether the server allows clients to use oplocks on files.
Oplocks are a significant performance enhancement, but have the
potential to cause lost cached data on some networks, particularly
wide-area networks.
By default, the registry entry is 1 (oplock enabled), as a rule
of thumb you should set this key to 0 (disable oplock) when sharing
files with Xbase++/Clipper/FoxPro and MS-Access. We have not encountered
any performance drawbacks in real-world scenarios after having disabled
oplocks. However problems with Xbase++ file-based database applications
simple went away after re-configuration of the server.

Source: http://www.superbase.com/services_tech_support_oplocks.htm

[Contenu sponsorisé]