Pourquoi mon produit BOC est-il lent ? 31 mars 2026 11:58 Mise à jour Problème : Temps de réponse longs, mauvaise performance Certaines (ou toutes) les fonctions de votre produit BOC (ADONIS, ADOIT ou ADOGRC) fonctionnent anormalement lentement et mettent beaucoup de temps à s’exécuter :Parfois, un produit BOC semble ralentir au fil du temps. Dans certaines circonstances, des charges de travail de pointe provoquent temporairement des temps de réponse médiocres, qui se normalisent ensuite. Des travaux de maintenance en cours dans votre infrastructure informatique peuvent entraîner des temps de réponse temporairement lents. Des modifications permanentes de votre infrastructure informatique peuvent également entraîner une détérioration des temps de réponse.Pour améliorer les temps de réponse médiocres, suivez les solutions décrites ci-dessous. Solution 1 : Mettre à jour les statistiques de la base de données Client WebCe guide s'applique à ADONIS 16, ADOIT 17, et ADOGRC 13 et versions ultérieures. Pour les instructions applicables aux versions antérieures, veuillez cliquer ici. Étape Description Image 1 Connectez-vous à l’administration du client web 2 Dans l’écran d’accueil, choisissez Plus d’options 3 Dans l’onglet Outils, sélectionnez Mettre à jour les statistiques de la base de données. 4 Cliquez sur Exécuter pour lancer la mise à jour des statistiques de la base de données. Cette fonctionnalité optimise les temps d’accès à la base de données. La fonction met à jour non seulement les statistiques sur la distribution des données, mais défragmente également les données dans la base et reconstruit les index de base de données pertinents. Dans de nombreux cas, cette mesure conduit à une amélioration significative des performances des produits BOC.Remarque : La mise à jour des statistiques de la base de données prend généralement de quelques secondes à 30 minutes ou plus, selon la taille de la base de données. Pendant la mise à jour des statistiques, les temps de réponse pour les autres utilisateurs peuvent temporairement se détériorer davantage car le processus de mise à jour crée une charge supplémentaire sur le système de base de données. Il est recommandé de mettre à jour les statistiques de la base de données à un moment où peu d’utilisateurs utilisent votre produit BOC. Il est recommandé de mettre à jour les statistiques de la base de données via l’Administration Toolkit au moins une fois par semaine. Client richeCes instructions s’appliquent aux versions antérieures à ADONIS 16, ADOIT 17 et ADOGRC 13. Pour les instructions applicables aux versions ultérieures, veuillez cliquer ici. Dans l’Administration Toolkit, depuis le menu Paramètres, lancez Mettre à jour les statistiques de la base de données.... Cette fonctionnalité optimise les temps d’accès à la base de données. La fonction met à jour non seulement les statistiques sur la distribution des données, mais défragmente également les données dans la base et reconstruit les index de base de données pertinents. Dans de nombreux cas, cette mesure conduit à une amélioration significative des performances des produits BOC.Remarque : La mise à jour des statistiques de la base de données prend généralement de quelques secondes à 30 minutes ou plus, selon la taille de la base de données. Pendant la mise à jour des statistiques, les temps de réponse pour les autres utilisateurs peuvent temporairement se détériorer davantage car le processus de mise à jour crée une charge supplémentaire sur le système de base de données. Il est recommandé de mettre à jour les statistiques de la base de données à un moment où peu d’utilisateurs utilisent votre produit BOC. Il est recommandé de mettre à jour les statistiques de la base de données via l’Administration Toolkit au moins une fois par semaine. Regardez cette courte vidéo sur la mise à jour de vos statistiques de base de données : Solution 2 : Attendre la fin des événements externes Des événements externes sur lesquels vous n’avez aucune influence peuvent ralentir temporairement le système : des travaux de maintenance peuvent être effectués dans votre infrastructure informatique (à votre insu), ou des charges de travail de pointe dans d’autres logiciels peuvent ralentir le système. D’autres événements temporaires peuvent également avoir un impact.Remarque : Si vous utilisez un produit BOC depuis le BOC Cloud (SaaS), les activités de maintenance effectuées par BOC sont toujours annoncées à l’avance par e-mail (sauf en cas de maintenance d’urgence à court terme).Attendez donc un certain temps jusqu’à ce que les travaux de maintenance (ou autres événements) puissent être terminés. Cela se produit généralement en quelques heures, mais peut aussi prendre jusqu’au jour ouvrable suivant. Si nécessaire, contactez votre équipe informatique pour être informé des activités de maintenance en cours.Si les temps de réponse médiocres sont dus à des activités de maintenance informatique ou à d’autres événements temporaires, les temps de réponse reviendront à la normale une fois ces événements terminés. Dans ce cas, aucune autre action n’est requise. Solution 3 : Redémarrer les services REMARQUE : Vous ne pouvez utiliser cette approche que si votre produit BOC est installé dans votre propre infrastructure (sur site). Si vous utilisez un produit BOC depuis le BOC Cloud (SaaS), BOC effectuera les étapes nécessaires selon les besoins. Dans de rares cas, des effets domino internes d’actions intensives en charge et bloquantes peuvent entraîner une détérioration des temps de réponse. Cela peut être corrigé en redémarrant les services du produit BOC.Arrêtez tous les services du produit BOC puis redémarrez-les : Le Service du serveur d’application Et le Service du serveur web Puis attendez quelques minutes (jusqu’à 1 heure ou plus pour des scénarios très volumineux) jusqu’à ce que les services aient été démarrés et initialisés avec succès.Important : Notez qu’un redémarrage des services mettra fin à toutes les sessions utilisateur en cours sans permettre aux utilisateurs de sauvegarder leurs dernières modifications. Pendant un redémarrage, aucun utilisateur ne peut accéder au produit BOC. Il est donc recommandé d’effectuer un redémarrage uniquement pendant une fenêtre de maintenance. Solution 4 : Identifier les changements système pertinents Les temps de réponse de votre produit BOC étaient très probablement corrects à un moment antérieur. Demandez-vous donc : Qu’est-ce qui a changé et qui pourrait être à l’origine des temps de réponse plus lents ?Les changements typiques pouvant causer des problèmes de performance incluent : Modifications de votre infrastructure informatique (mise à jour des composants matériels ou logiciels, modification de la configuration réseau, changements de serveur, etc.). Activation de nouvelles interfaces vers des systèmes tiers. Ateliers, formations et autres événements où beaucoup plus d’utilisateurs accèdent au produit BOC que d’habitude. Moments de charges exceptionnellement élevées (par exemple, pics de charge en fin de trimestre). Nouveaux emplacements, par exemple accès depuis le télétravail au lieu du site habituel de l’entreprise. Mise à jour de la version ou de la configuration de votre produit BOC. Migration de composants de votre produit BOC vers une nouvelle infrastructure (par exemple vers d’autres serveurs). Autres changements. Une fois que vous avez identifié le changement pertinent, réfléchissez s’il est temporaire ou s’il peut être inversé.Vous pourriez également constater que votre système n’est pas dimensionné de manière adéquate pour les pics de charge. Dans ce cas, augmentez les ressources système disponibles. Solution 5 : Vérifier l’utilisation de l’API REST Avez-vous intégré un système externe à votre produit BOC et utilisez-vous l’API REST d’ADONIS, ADOIT ou ADOGRC ?Si oui, assurez-vous que le nombre de requêtes REST par heure ne dépasse pas la valeur maximale recommandée. Effectuez les mises à jour de données avec une communication REST intensive en heures creuses, lorsque peu d’utilisateurs accèdent au système. Si nécessaire, réduisez le nombre de requêtes REST.Si votre implémentation REST semble nécessiter trop de requêtes REST, contactez votre gestionnaire de compte client BOC. Il peut être possible de trouver une implémentation plus efficace avec l’aide de nos équipes solutions. Solution 6 : Vérifier le réseau Vérifiez la vitesse et la bande passante de la connexion réseau entre le serveur d’application et le serveur de base de données, ainsi qu’entre les autres composants de votre installation produit. Comparez la performance réseau actuelle aux exigences de votre produit BOC : Exigences réseau pour ADONIS Exigences réseau pour ADOIT Exigences réseau pour ADOGRC Connexion réseau entre serveur d’application et serveur de base de données Vitesse réseau : Un temps aller-retour (RTT) de <= 1 ms est recommandé entre le serveur d’application et le serveur de base de données. Un temps aller-retour (RTT) d’au moins <= 3 ms est requis entre le serveur d’application et le serveur de base de données. Bande passante :Pour vérifier la bande passante disponible, lancez le Administration Toolkit sur le même ordinateur où le serveur d’application de votre produit BOC est en fonctionnement. Sélectionnez ensuite le menu Paramètres > Analyser la bande passante... et lancez le test de bande passante.Le résultat montre des valeurs de référence pour des temps de réponse optimaux, ainsi que vos valeurs actuelles. Si vos valeurs actuelles sont légèrement supérieures aux valeurs optimales, cela ne pose généralement pas de problème. Cependant, si dans de nombreuses catégories vos valeurs actuelles sont des multiples des valeurs optimales, alors la bande passante ou la latence de votre réseau pourrait être la cause des temps de réponse lents. En cas de doute, contactez le support technique BOC pour une évaluation des résultats du test de bande passante.Connexion réseau entre client et serveur web Une connexion réseau lente ou instable entre le client et le serveur web peut par exemple ralentir les cas d’utilisation suivants : Ouverture de l’URL vers votre produit BOC. Durée jusqu’à l’apparition de l’écran de connexion. Ouverture du carnet de notes d’un objet. Durée jusqu’à ce que toutes les données soient entièrement chargées et affichées dans le carnet. Durée d’accès à l’API REST de votre produit BOC. Assurez-vous d’une connexion réseau stable qui répond aux exigences de bande passante de votre produit BOC. Gardez à l’esprit qu’une connexion wifi depuis le télétravail ou en déplacement présente souvent des latences plus élevées et moins de stabilité que la connexion LAN sur un site d’entreprise.Identifier la perte de paquets :Sur le serveur web, ouvrez le répertoire où se trouvent les fichiers journaux du serveur web. Par défaut, il s’agit du répertoire "<répertoire d’installation Apache Tomcat>\logs".Dans le répertoire des journaux, identifiez le fichier "<produit>_Core.log" (par exemple "ADONIS15.0.0_Core.log").Ouvrez ce fichier journal dans un éditeur de texte et recherchez les mots-clés suivants autour de l’heure des problèmes de performance : "action:", "actionp:", "webmethod:".Ces mots-clés sont généralement suivis de trois nombres, tels que "actionp:242166-666606-57". Le dernier nombre (ici "57") est le numéro consécutif de la requête. Ce nombre augmente toujours et continuellement tant que les deux premiers nombres restent les mêmes (voir figure). S’il y a des trous dans la séquence des nombres, cela indique que les requêtes correspondantes n’ont pas été reçues par le serveur web. Dans des cas isolés, cela peut arriver de temps en temps, mais si cela se produit à plusieurs reprises, contactez votre équipe informatique pour améliorer la stabilité du réseau ou envisagez un accès depuis un autre emplacement ou réseau. Solution 7 : Supprimer les anciennes données Supprimez les données dont vous n’avez plus besoin, telles que d’anciens modèles, objets ou référentiels.Assurez-vous de mettre à jour les statistiques de la base de données après avoir supprimé de grandes quantités de données !Important : Il est fortement recommandé de créer une sauvegarde de la base de données avant de supprimer des données. Solution 8 : Vérifier l’utilisation de la base de données REMARQUE : Vous ne pouvez utiliser cette approche que si votre produit BOC est installé dans votre propre infrastructure (sur site). Si vous utilisez un produit BOC depuis le BOC Cloud (SaaS), BOC effectuera les étapes nécessaires selon les besoins. Contactez votre équipe base de données et faites vérifier la charge sur le serveur de base de données à un moment où les temps de réponse lents dans votre produit BOC se produisent réellement.Si la base de données ou le serveur de base de données est surchargé, votre équipe base de données peut généralement corriger cela par des ajustements de configuration. Solution 9 : Augmenter les ressources système REMARQUE : Vous ne pouvez utiliser cette approche que si votre produit BOC est installé dans votre propre infrastructure (sur site). Si vous utilisez un produit BOC depuis le BOC Cloud (SaaS), BOC effectuera les étapes nécessaires selon les besoins. Vérifiez l’utilisation des ressources système les plus importantes sur le serveur web, sur le serveur d’application et sur le serveur de base de données de votre produit BOC : CPU RAM (mémoire) Réseau Taille maximale de la mémoire Java du serveur web : Si nécessaire, augmentez la "piscine mémoire maximale" de votre installation Apache Tomcat. Avant cela, assurez-vous cependant que le serveur web dispose d’une mémoire physique (RAM) suffisante pour pouvoir fournir la "piscine mémoire maximale" augmentée. Pour les scénarios petits et moyens, une "piscine mémoire maximale" de 2048 Mo est généralement suffisante. Des valeurs beaucoup plus élevées peuvent être nécessaires pour les grands scénarios. Augmentez les ressources système qui sont fortement sollicitées.Gardez à l’esprit que des ressources système plus importantes sont nécessaires pour des pics ponctuels que pour des charges normales.Assurez-vous également que votre infrastructure répond aux exigences système de BOC Management Office. Vous trouverez les exigences système minimales dans la description des Exigences matérielles/logiciels de votre produit : Exigences matérielles/logiciels pour ADONIS. Exigences matérielles/logiciels pour ADOIT. Exigences matérielles/logiciels pour ADOGRC. Solution 10 : Identifier les utilisateurs affectés Déterminez si tous ou seulement certains utilisateurs sont concernés par la dégradation des temps de réponse. Si seuls certains utilisateurs sont affectés, considérez ce qui les différencie des autres utilisateurs (non affectés) : Seuls les utilisateurs avec des cas d’utilisation spécifiques sont-ils affectés ? (par exemple, uniquement ceux qui génèrent certains rapports, etc.) Seuls les utilisateurs de certaines zones géographiques sont-ils affectés ? Seuls les utilisateurs accédant à certains moments sont-ils affectés ? Une fois que vous avez identifié la différence pertinente entre les utilisateurs affectés et non affectés, cela indiquera probablement la résolution du problème de performance. Solution 11 : Vérifier les journaux REMARQUE : Vous ne pouvez utiliser cette approche que si votre produit BOC est installé dans votre propre infrastructure (sur site). Si vous utilisez un produit BOC depuis le BOC Cloud (SaaS), BOC effectuera les étapes nécessaires selon les besoins. Sur le serveur d’application, ouvrez le répertoire où se trouvent les fichiers journaux de votre produit BOC. Par défaut, il s’agit du répertoire "<répertoire d’installation BOC>\logs".Dans le répertoire des journaux, identifiez les fichiers avec les noms suivants et un horodatage correspondant au moment de vos problèmes de performance : "<horodatage>_aworker.log" "<horodatage>_aserver.log" Ouvrez ces fichiers journaux dans un éditeur de texte et recherchez les entrées suivantes autour du moment des problèmes de performance : Fichier Entrée du journal Signification ...aworker.log "[WARN] Problème de performance : m_pDataSource" Cette entrée indique des réponses lentes du système de base de données. Cela peut être dû à une surcharge du serveur de base de données ou à une connexion réseau lente entre le serveur d’application et le serveur de base de données. Vérifiez la charge de la base de données, et la vitesse du réseau. ...aserver.log "La valeur de la mémoire de travail du processus est au-dessus du seuil d’alerte" Cette entrée indique que votre produit BOC utilise une quantité inattendue de mémoire. Vérifiez s’il y a suffisamment de mémoire principale libre (RAM) sur le serveur d’application et augmentez la RAM disponible si nécessaire. Si suffisamment de RAM est disponible et que cette entrée de journal s’affiche toujours, contactez le support technique BOC pour une analyse approfondie. ...aserver.log "la mémoire est en dessous du seuil d’alerte" Cette entrée montre qu’il n’y a pas assez de mémoire principale libre (RAM) disponible sur le serveur d’application. Augmentez la RAM sur le serveur. ...aserver.log "État de la mémoire système" Cette entrée montre la quantité de mémoire principale (RAM) disponible au moment de l’entrée du journal, à la fois en total et libre. Par exemple, l’entrée complète pourrait ressembler à ceci : "État de la mémoire système (total / disponible) : 16383 Mo / 543 Mo" - S’il y a peu de mémoire disponible (moins de 2 Go ou moins de 10 % de la mémoire totale), augmentez la RAM disponible sur le serveur. ...aserver.log "phys-avail" Cette entrée fait partie d’une ligne de journal plus longue qui fournit des informations sur l’utilisation de la mémoire au moment de l’entrée du journal. Par exemple, l’entrée complète pourrait ressembler à ceci : "working-set : 1005 Mo working-set-max : 1012 Mo paged-current : 1281 Mo paged-max : 1368 Mo phys-avail : 2024 Mo virtual-avail : 123218028 Mo" - Si la valeur après "phys-avail" est très faible (moins de 1 Go), envisagez d’augmenter la RAM disponible sur le serveur. Si les valeurs sont ambiguës, contactez le support technique BOC pour une analyse approfondie. Tous les fichiers journaux Autres entrées de journal D’autres entrées de journal autour du moment des problèmes de performance peuvent également fournir des informations sur la cause principale. Si nécessaire, soumettez les journaux (de préférence sous forme de paquet d’informations de support) au support technique BOC pour une analyse approfondie. Notez qu’une analyse approfondie peut prendre beaucoup de temps. Autres causes Si les solutions fournies dans cet article ne résolvent pas le problème, contactez le support technique BOC.En particulier, fournissez les informations suivantes : Un cas d’utilisation spécifique où les temps de réponse sont anormalement lents. Moment d’occurrence : date et heure du cas d’utilisation lent. Mesures réelles des temps de réponse : combien de temps le cas lent a-t-il duré en secondes, minutes ou heures ? Si vous exploitez le produit BOC dans votre propre infrastructure (sur site) : un paquet d’informations de support (SIP) actuel. Quelles solutions de cet article avez-vous déjà mises en œuvre et avec quel résultat ? Articles associés Comment télécharger un SIP (Support Information Package) ? Comment résoudre une panne (SaaS) ? Comment configurer la surveillance de l'état de mon produit BOC ? Le produit BOC échoue après les ajustements TLS Comment migrer la configuration côté Tomcat d’un produit BOC ?