Aller au contenu principal

Évaluation de la performance

Cette section vous aide à vérifier et à comprendre les facteurs qui peuvent affecter la vitesse et la performance globale de SEI. Les informations ici sont techniques et mieux adaptées à ceux qui sont à l'aise avec les serveurs, les bases de données ou les paramètres réseau.

La plupart du temps, si vous rencontrez des rapports lents ou des délais, cela est causé par des éléments extérieurs à SEI—tels que votre serveur, votre base de données, votre réseau ou votre source de données.

Avant de commencer à utiliser SEI, il est conseillé de revoir la configuration de votre système et de vous assurer que tout fonctionne correctement. Les conseils et exemples ici, axés sur SQL Server et Sage X3, vous aident à identifier et à résoudre les problèmes les plus courants.

Volume de données​

Évaluer le volume de données dans vos sources de données—en particulier la source principale—est crucial pour optimiser la performance de SEI.

Suivez ces étapes pour évaluer et surveiller le volume de données :

  1. Vérifiez la taille globale de la base de données.
    Passez en revue la taille physique de la base de données de votre source de données principale. Dans SQL Server, vous pouvez trouver cette information sur l'écran des Propriétés de la base de données.
  2. Examinez les tailles des tables clés (nombre de lignes).
    Identifiez les tables ou fichiers critiques (tels que Clients, Articles d'inventaire, Détail de facturation, Journal de stock, Journal de grand livre). Exécutez la requête SQL suivante pour chaque table afin de voir le nombre d'enregistrements : 
    SELECT COUNT(*) FROM <YourTableName>
  3. Testez la performance des requêtes côté serveur.
    Utilisez un outil comme SQL Server Management Studio pour exécuter des requêtes typiques directement sur le serveur. Choisissez des requêtes qui sont représentatives d'un usage réel des rapports et ciblez de grandes tables. Exemples de requêtes : 
    SELECT TOP 500000 * FROM yourERP_CustomersTable
    SELECT TOP 500000 * FROM yourERP_GLJournalTable
    SELECT TOP 500000 * FROM yourERP_InvoiceTable
    Idéalement, la récupération de 500 000 enregistrements devrait prendre moins de 20 secondes. Sinon, examinez la configuration et les ressources du serveur.
  4. Testez la réponse des requêtes sur le réseau local (LAN).
    Exécutez les mêmes requêtes depuis un autre ordinateur à l'intérieur du LAN de l'entreprise. Si la performance diminue, enquêtez sur la configuration réseau locale.
  5. Testez la réponse des requêtes sur une connexion distante (WAN).
    Exécutez les requêtes depuis un ordinateur distant via le WAN. Si les temps de réponse augmentent considérablement, vérifiez l'infrastructure et la connectivité WAN, car cela peut avoir un impact sévère sur la performance.

remarque

La plupart des problèmes de performance à ce stade sont liés à votre moteur de base de données ou à l'infrastructure serveur/réseau—et non à l'application SEI elle-même.

Pour un dépannage plus approfondi, consultez Performance du moteur de base de données et Performance du matériel, ou consultez un spécialiste technique.

Performance​

Cette section se concentre sur l'optimisation des modèles de données de SEI, des cubes OLAP et de l'utilisation de l'Add-in Excel. Ces optimisations aident à prévenir les problèmes de performance au sein de l'application elle-même.

Assurez-vous que la performance du serveur et du réseau est déjà confirmée avant d'appliquer ces étapes.

Optimisation des modèles de données​

Si vous constatez des performances lentes avec une vue de SEI, commencez par déterminer si elle est construite sur un modèle de données ou un cube. Si elle est basée sur un cube, reportez-vous à la sous-section suivante. Pour les modèles de données, suivez ces étapes :

Pour les Modèles de données lents :​

  1. Localisez la requête SQL utilisée par le modèle de données dans le fichier journal de SEI. (Voir SEI Logs pour l'emplacement des fichiers.)
  2. Copiez et exécutez la requête directement dans un client SQL (tel que SQL Server Management Studio) sur le serveur de base de données.
  3. Analysez et optimisez la requête si nécessaire et envisagez d'ajouter des index pour améliorer la vitesse.
attention

Pour Sage ERP sur SQL Server, utilisez toujours les outils recommandés par Sage pour ajouter des index, sinon vos modifications peuvent être perdues lors des mises à niveau.

Optimisation de l'Add-in Excel​

Lorsque vous rencontrez des problèmes de performance avec l'Add-in Excel, commencez par identifier quel modèle de données le rapport utilise et optimisez d'abord ce modèle de données à l'intérieur de SEI. Vérifiez le journal SEI pour voir la requête SQL derrière votre rapport d'Add-in Excel. (Voir SEI Logs pour l'emplacement des fichiers.)

Après avoir optimisé le modèle de données à l'intérieur de SEI, utilisez ces directives supplémentaires si la performance d'Excel est toujours lente :

  1. Examinez le nombre de formules Excel dans le rapport.
    Trop de formules (en particulier réparties sur plusieurs feuilles) sont une raison courante de la lenteur d'Excel.
    Pour améliorer l'efficacité, utilisez des paramètres (comme des boîtes combinées) qui permettent aux utilisateurs de filtrer les données et de réduire à la fois le nombre et la complexité des formules.
  2. Vérifiez le Paramètre de cache de l'Add-in Excel.
    Un paramètre de cache incorrect est une cause fréquente de problèmes de performance avec l'Add-in.
    Vérifiez ce paramètre, et envisagez une formation supplémentaire pour garantir une configuration de cache appropriée pour votre environnement.

Pour plus de détails et d'astuces sur l'optimisation des références et des formules, consultez Cache Optimizer.

Performance du moteur de base de données​

Si vous avez écarté SEI comme source de ralentissements mais que vous rencontrez toujours des problèmes de performance, examinez l'utilisation des ressources et la configuration de votre serveur de base de données. Pour SQL Server, deux facteurs majeurs sont clés : la mémoire disponible et les entrées/sorties disque.

Paramètres de mémoire du serveur de base de données​

  • Assurez-vous que le paramètre Mémoire maximale du serveur dans SQL Server n'est pas configuré pour utiliser toute la RAM du serveur. Permettre à SQL Server d'utiliser toute la mémoire disponible peut priver d'autres applications et services s'exécutant sur le serveur.
    Exemple : Si le serveur est dédié uniquement à SQL Server, allouer la plupart de la mémoire à SQL Server est raisonnable. Si le serveur exécute également d'autres applications ou services, laissez suffisamment de mémoire réservée pour ceux-ci également.
  • En règle générale, configurez SQL Server pour qu'il utilise un maximum d'environ 80 % de la RAM totale (un ajustement plus précis peut être nécessaire en fonction de la charge de travail du serveur).
  • En cas de doute, consultez un spécialiste technique pour déterminer la bonne valeur pour votre environnement.

Surveiller les ressources système en utilisant PerfMon​

Collectez des statistiques pendant au moins 15 minutes lors de la charge de travail typique à l'aide de Windows Performance Monitor (PerfMon). Portez une attention particulière à ces compteurs clés :

  • Pages par seconde (Compteur de mémoire) :
    Suivi de la quantité de mémoire que le serveur pagine activement vers/depuis le disque.
    Des valeurs constantes supérieures à 150 suggèrent un goulot d'étranglement de mémoire. De fortes valeurs peuvent également être causées par d'autres facteurs—consultez un spécialiste pour une analyse approfondie.
  • Durée de vie de la page (Gestionnaire de mémoire tampon SQL Server) :
    Indique combien de temps les données restent dans le pool de mémoire tampon de SQL Server avant d'être évincées.
    Des valeurs supérieures à 300 secondes (5 minutes) sont idéales ; des chiffres constamment plus bas signifient souvent que le serveur a besoin de plus de mémoire.
  • Longueur moyenne de la file d'attente du disque :
    Montre combien de demandes d'entrée/sortie attendent d'être traitées par le disque.
    Des valeurs constamment supérieures à 2 peuvent suggérer que le disque ne gère pas efficacement la charge. Envisagez de mettre à niveau la vitesse du disque ou de revoir les schémas d'entrée/sortie.
  • % Temps processeur :
    Mesure la proportion de temps que le processeur est occupé.
    Des valeurs soutenues supérieures à 70 % indiquent un stress du CPU et peuvent signaler un besoin de plus de puissance de traitement.

Ces métriques doivent être interprétées dans le contexte de la charge de travail et de l'environnement de votre serveur. Consultez toujours un spécialiste technique expérimenté pour une analyse complète et avant de procéder à des modifications de configuration importantes.

Performance du matériel​

Les problèmes de performance peuvent résulter du matériel de votre serveur, que ce soit avant ou après l'installation de SEI.

  • Si des problèmes surviennent avant que SEI ne soit installé, consultez un spécialiste technique pour identifier la cause. Les sources courantes incluent :
    • Configuration ou infrastructure réseau, tels que VPN ou configuration LAN. Testez la performance en exécutant des requêtes sur chaque type de connexion réseau.
    • Surcharge du serveur ou dimensionnement incorrect. Le serveur peut manquer de ressources adéquates pour la charge de travail actuelle.
  • Si des problèmes commencent uniquement après l'installation de SEI, passez en revue et optimisez votre configuration Nectari comme indiqué dans les sections Performance et Performance du moteur de base de données. Si les problèmes persistent, évaluez si le matériel du serveur est dimensionné adéquatement pour des applications simultanées.