wiki:v15:tech:temps_reponse

Temps de réponse

Les critères pouvant influer sur les performances en temps de réponse sont répertoriés ci-dessous :

  1. vélocité des processeurs des machines hébergeant les instances de programme (ici, Gestan ou le serveur HFSQL)
  2. quantité de mémoire vive disponible
  3. vélocité des disques de stockage
  4. espace libre restant disponible sur le disque
  5. tâches effectuées par l'OS en parallèle (Windows Update, notamment)
  6. autres tâches effectuées en parallèle (dont anti-virus, anti-malware, ou autre anti-xx) et conflits éventuels
  7. autre services effectués par la machine (dont services éventuellement plantés)
  8. qualité du réseau local et des switches
  9. mise à jour des systèmes et homogénéité du parc machine
  10. réglage du serveur HFSQL (en client/serveur)
  11. volumétrie des bases de données
  12. nombre d'utilisateurs effectuant des opérations simultanément

(Vitesse de processeur, RAM, HDD)

Ces critères sont mesurables facilement, donc améliorables facilement. Une machine “standard” de 2022 - W10 ou W11 avec 4 ou 8Go de Ram et un disque SSD - n'aura aucune difficulté à faire fonctionner Gestan en monoposte.

Bien que cela soit possible, nous ne recommandons pas d'installer les données de Gestan sur un NAS. Les NAS sont faits pour faire du streaming, ou du stockage de photos ou d'archives, et ils sont d'ordinaires bien plus lents qu'un serveur de données (certains NAS sont très performants sur ce point mais ils coûtent alors aussi cher qu'un serveur de données). Il est préférable d'utiliser un serveur de données fait pour cela, sous Linux ou sous Windows.

Si vos données sont installées sur un disque accessible via votre réseau interne, les temps de réponse dépendent de la qualité et de la charge de votre réseau.

Dans la mesure du possible, évitez les réseaux Wifi, les réseaux câbles sont à la fois plus fiables et plus rapides.

Pour ce qui concerne la charge du réseau : il suffit de s'assurer que Gestan n'est pas en concurrence avec un autre processus qui viendrait charger le réseau à l'excès (backup, streaming, etc.), c'est facile.

Pour la qualité du réseau, c'est plus délicat à vérifier. Il faut en effet contrôler les câblages, les switches et les hubs, ainsi que les cartes réseau. Si vous avez des doutes à ce sujet, nous recommandons de faire effectuer ce travail par un prestataire informatique équipé des outils et logiciels nécessaires.

Gestan peut fonctionner sur des volumétries très importantes : le plus important client Gestan à ce jour émet environ 10.000 factures par mois depuis 2015, la limite théorique étant de 2 millions de milliards d'enregistrements pour un enregistrement de 4.096 octets. Cela laisse le temps de voir venir.

Cependant, un fichier d'un million d'enregistrements ne se manie pas comme un fichier de dix enregistrements : il convient, dans le cas de fichiers importants, d'utiliser les options d'optimisation disponibles pour les écrans : table des contacts, table des produits, table des mouvements de stock, etc. L'écran Benchmark lectures permet à tout administrateur Gestan de faire ces optimisations pour tous les utilisateurs (ils pourront modifier ce réglage individuellement si nécessaire).

Le nombre d'utilisateurs connectés simultanément interfère avec la volumétrie : si 200 utilisateurs lisent en même temps un fichier d'un million d'enregistrement, la sollicitation du processeur portant la base sera importante.

A partir d'une dizaine d'utilisateurs connectés, nous recommandons le mode d'utilisation en mode Client/Serveur.

L'analyse et l'optimisation des temps de réponse est un travail qui nécessite de la réflexion, du temps, et de l'expérimentation. Il n'y a pas de solution magique qui permette, d'un claquement de doigt, de transformer une installation bancale en bête de course !

En cas de temps de réponse insatisfaisants, la méthodologie la plus efficace consiste d'abord à poser un bon diagnostic, puis, si ce diagnostic ne permet pas de traiter le problème, à vérifier une situation saine, pour aller graduellement vers une situation dégradée, afin d'identifier l'élément responsable de la dégradation.

Donc :

  • Commencez par diagnostiquer précisément le problème
  • Si le diagnostic ne permet pas de résoudre le problème, testez Gestan dans la configuration la plus simple
  • Puis compliquez les choses, avec un seul élément à chaque fois, et vérifier l'impact de chaque élément ajouté.

Cette méthodologie permet d'identifier l'élément responsable du problème, et d'y apporter correction.

Par exemple : vous avez 200 utilisateurs avec une installation en client/serveur.

  • commencer par diagnostiquer le problème avec précision : en cas de problème de temps de réponse, commencez par identifier précisément quels écrans/programmes posent problème, dans quel cas d'usage. Bien souvent, un simple réglage des options de l'écran permet d'améliorer nettement les performances. Par exemple, si vous faites de très nombreuses factures, et que vous les affichez par an, il suffit dans les options de l'écran de les afficher par mois pour améliorer les performances de l'écran par 12 ! L'écran de benchmark permet de mesurer les temps de réponse, et d'optimiser les options pour tous les utilisateurs à la fois.
  • si le diagnostic et les optimisations effectuées n'ont pas permis de rétablir de bons temps de réponse, installez le programme Gestan sur la machine qui sert de serveur physique de données, et accédez avec un seul utilisateur aux données en connexion Classique (non Client/Serveur). Cette configuration est celle qui donne par nature les meilleurs temps de réponse. Vérifiez que pour les programmes/usages que vous avez identifié comme posant problème, les temps de réponse sont excellents. Si tel n'étais pas le cas, il est recommandé de faire appel au support technique, qui pourra trouver des optimisations de programme.
  • puis accédez aux données en connexion Classique via le réseau → cela permet de vérifier l'impact du réseau sur les temps de réponse. Testez les postes informatiques qui sont sur des switchs/hubs différents (il peut arriver qu'un switch pénalise certains postes, tandis que les autres fonctionnent correctement).
  • puis accédez aux données en mode Client/Serveur (si vous étiez en Client/Serveur) → cela permet de vérifier l'impact du serveur HFSQL. Vérifiez le réglage du serveur HFSQL, notamment la mémoire cache.
  • enfin, testez la montée en charge avec vos 200 utilisateurs connectés.
  • Pour faire le ménage dans votre PC, nous recommandons l'utilitaire CCleaner, un programme d'optimisation et de nettoyage, disponible en version gratuite. Via cet utilitaire, nettoyez le cache de Windows, cela peut améliorer la vitesse (merci Pascallo ;-))
  • Pour contrôler la vitesse en lecture/écriture de vos disques : CrystalDiskMark
  • l'état du verrouillage optimiste des fichiers (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters ou HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters selon les versions) peut influer, selon les versions de Windows (voir un spécialiste).
  • la désactivation de SMB peut aussi donner des résultats intéressants (voir un spécialiste).
  • Excluez le répertoire de votre database ou les fichiers .fic, .ndx, .mmo de l'antivirus du serveur.

Autres articles “Technique”

  • wiki/v15/tech/temps_reponse.txt
  • Dernière modification : 2022/07/04 23:44
  • de eneuville