Requêtes ODBC (très) lentes

[TBM]

Bonjour tout le monde,

L'entreprise pour laquelle je travaille utilise Acomba de la façon suivante : l'application et la base de données sont installées sur un server roulant Windows Server 2003 et chaque poste de travail se connecte au serveur pour exécuter Acomba (via un "lecteur réseau"). De la même façon, j'utilise un lien ODBC dans Access pour accéder à BD à partir du serveur. Utilisé de cette façon, Acomba est extrêmement lent, les requêtes SQL via ODBC sont instables et Access crash souvent.

Par contre, voici le point important. Lorsqu'on se connecte à distance (remote connection) au serveur, autrement dit, qu'on utilise le poste de travail uniquement comme terminal, Acomba fonctionne très bien, les requêtes ODBC sont beaucoup plus rapides, on n'a pas de "Ce produit ne répond pas", etc.

J'essaie depuis quelques jours de trouver une solution, mais le nombre de paramètres pouvant entrer en ligne de compte est vraiment très important. Mais pour le moment, j'aimerais surtout savoir s'il s'agit d'un problème de software (Acomba est mal installé, BD de données trop lourde, mauvaise configuration sur le serveur ou sur les postes de travail...) ou de hardware.

Auriez vous donc quelques suggestions à me donner pour que je puisse au moins éliminer quelques variables du problème et tenter d'isoler la source de cette lenteur.

[Lartis]

Bonjour,

Première suggestion, désactiver tous les antivirus, autant sur le serveur que sur les stations, en déploguant le modem si vous voulez ne prendre aucun risque. Souvent, les problèmes de performance sont reliés à des antivirus qui scannent les fichiers en loop. Acomba n'utilise pas un véritable système de base de données, mais un système propriétaire qui oblige le système à transférer continuellement des gros fichiers par le réseau pour les ouvrir localement. Si ça corrige le problème, assurez vous d'exclure les répertoires Acomba des antivirus. (au minimum, exclure les extension .FIW, FDW, DBF, CDX et .INI.)

2e suggestion: réseau Gigabit. Ça va de soit, ça pourrait améliorer la situation si bottleneck est le transfert réseau.

3e suggestion: si le problème est vraiment important, et que rien d'autre ne fait, il est possible d'utiliser Acomba en RDP (terminal server) sur le serveur. Plusieurs de mes gros clients qui avaient des problèmes de performance ont passé à cette solution et l'amélioration est drastique. Ça revient à utiliser intensivement les ressources du serveur, mais réduire au minimum l'utilisation du réseau et des stations. Pour cette situation, un serveur "solide" est recommandé: très bon processeur, beaucoup de mémoire, et surtout des disques rigides très rapides. S'il y a peu d'usagers, le serveur actuel peut surement faire l'affaire.

L'inconvénient de cette solution peut être de ralentir, voir même rendre instable, le serveur. Ça peut donc avoir un impact sur la performance des autres utilisations du serveur, et causer d'autres problèmes. Il faut donc faire attention, et peut-être s'assurer que les usagers ont des droits très limités sur le serveur, pour éviter par exemple que les usagers installent des programmes sur le serveur.

Selon mon expérience, le hardware qui a le plus d'impact sur la performance d'Acomba, c'est nettement la vitesse du disque dur sur lequel les données Acomba (F1000.DTA par défaut) sont présentes. Le disque ou se trouve le programme lui même (C:\Fortune par défaut) n'a que peu d'impact, puisqu'il n'aidera qu'à l'ouverture du programme.

[PlanteG]

Par contre, voici le point important. Lorsqu'on se connecte à distance (remote connection) au serveur, autrement dit, qu'on utilise le poste de travail uniquement comme terminal, Acomba fonctionne très bien, les requêtes ODBC sont beaucoup plus rapides, on n'a pas de "Ce produit ne répond pas", etc.

Ceci porte à penser que le nœud du problème est le transfert entre le serveur et les postes des utilisateurs. S'il y a un antivirus sur le serveur et les postes de travail, alors les données sont inspectées deux fois. Ouch . Juste le fait que le travail est effectué directement sur le serveur permet de retrancher beaucoup de temps.

L'engin de bd propre à Acomba n'est pas un serveur de données du tout. Donc les tables transitent au complet et sont épluchées sur le client. Ce problème sera réglé avec la prochaine génération d'Acomba. En attendant, il faut "faire avec" et mettre toutes les chances de son côté.

[Jeremie]

Bonjour,

Oui, c'est lent.

J'ai le même problème avec mes applications .Net.
Par contre, on avait aussi le problème en local et on a pas tester en Remote.

Il faut optimiser les requêtes SQL à morts et dans mon cas, il faut que j'ajoute un timer pour retarder mon logiciel sinon il crash.

En .Net, on peux aussi augmenté le timeout de la query, mais j'ai oublier comment avec Access.

Le seul truc qui à fonctionner dans 90% est l'optimisation des query.
Mettez le plus de condition possible dans le where.

Éviter les sous-requête et les jointures ...


Pour le fait que ça sois plus rapide en remonte, si j'ai bien compris la BD Acomba est sur le même serveur que celui qui est contrôler à distance ?

Si c'est ça, oui c'est plus rapide quand la Bd Acomba est sur la même machine.
Mais de là à faire une différence ...

[TBM]

Bonjour,

D'abord merci pour vos réponses. Ça donne pas mal de stock à considérer. Côté antivirus, je crois qu'on est plutôt clean, même chose pour la connection au serveur, on est sur gigabit. Mais je suis pas très calé côté réseau, alors je garde quand même un oeil de ce côté.

Cela dit, la solution de jérémie me semble la meilleure. Il faut dire que la plupart de mes requetes sont très "naives" et que j'utilise un certain nombre de sous-requetes. D'ailleurs, qu'elle est la bonne façon de procéder si on veut utiliser un "prédicat" intermédiaire? On enregistre le résultat d'une requete dans une nouvelle table temporaire? J'imagine que c'est valable, mais ça peut vite devenir lourd.

D'ailleurs, j'utilise en ce moment que quelques tables, essentiellement Products et ProductTrail. Products contient environ 35000 entrées, mais la plupart ne sont pas utilisées, n'ont jamais été utilisées et ne le seront sans doute jamais. Est-ce que c'est quelque chose d'impensable à gérer et que je devrais considérer purifier la BD ou bien si c'est une taille tout à fait normal qui ne devrait pas avoir trop d'incidence?

En tout cas, elle se fait attendre cette fameuse version 11

[Jeremie]

Bonjour,

Oui, le nombre de record joue un rôle dans la rapidité.
C'est pour cela qu'il faut avoir des requêtes le plus précis possible.

Pour se qui est des prédicats ... je dois dire que honnêtement, le terme ne me dit rien.
Et je n'ai pas essayer les tables temporaire non plus.

La prochaine version seras pas mal plus un nouveau produit qu'une simple mise à jour de version.
Vu tout le travaille qu'il doivent faire. C'est à dire carrément jeter Acomba au poubelle et repartir de zéro.

Nouveau langage de programmation, nouvelles technologie de BD, nouvelle norme de programmation, nouveau concepts ...

[bungto]

tu peux utiliser le plus nouvel version de sql server
--------------------------------------------
La baie d'halong|la baie d'along|Halong Croisière|halong jonque

[Contenu sponsorisé]