Pourquoi votre instance ServiceNow est-elle lente ?
« Lent » n'est pas un problème unique - ce sont plusieurs couches distinctes, que personne n'a généralement séparées avant d'essayer de les corriger. Voici comment le déterminer réellement.
« Lent » recouvre au moins cinq problèmes différents
Un simple chargement de page ou une transaction traverse plusieurs couches réellement distinctes, chacune pouvant échouer pour une raison différente. Corriger la mauvaise couche est la façon la plus courante dont une investigation de performance n'aboutit à rien.
Rendu côté client
Temps passé dans le navigateur lui-même - UI Policies, Client Scripts et rendu de la page. Semble lent même quand le serveur a répondu instantanément.
Aller-retour réseau
Temps que la requête et la réponse passent en transit. Souvent la vraie cause derrière les plaintes « c'est lent pour les utilisateurs distants » qui n'apparaissent jamais sur site.
Logique métier serveur
Business rules, script includes et logique de workflow/flow s'exécutant côté serveur avant même qu'une réponse puisse être construite.
Base de données
Le temps SQL réel - des requêtes sans index utilisable, ou une requête qui remonte bien plus de lignes que ce dont la page a besoin.
Intégrations avec des tiers
Un appel REST ou SOAP sortant, exécuté de façon synchrone dans la transaction, sans timeout - toute la page attend l'API d'un autre système.
Comment le vérifier réellement, sans deviner
ServiceNow enregistre déjà la majeure partie de cela - le diagnostic n'a généralement pas besoin d'un outil tiers.
Activer Client Transaction Timings
Si ce plugin de plateforme est actif, chaque ligne de syslog_transaction porte une véritable décomposition en millisecondes sur neuf champs - temps de réponse client, temps réseau client, temps navigateur, temps de script client, temps UI policy côté client ; temps de réponse serveur, temps réseau, temps des business rules et temps SQL côté serveur. Cette seule ligne indique laquelle des cinq couches ci-dessus domine réellement, au lieu de deviner au chronomètre.
Lire syslog_transaction directement
Même sans ce plugin, transaction_processing_time et business_rule_count sur la même table permettent de distinguer « le serveur était réellement occupé » de « quelque chose est lent côté client alors que le serveur a bien répondu ».
Pour les pages Next Experience / Workspace, vérifier sys_client_interaction
Un seul chargement de page peut couvrir plusieurs transactions serveur. Cette table donne plutôt la vue d'ensemble de la page entière - temps de chargement, temps jusqu'à l'interactivité, et un véritable taux de cache UI, pas une supposition sur le fait que le cache soit même en cause.
Les suspects habituels
Une fois la couche identifiée, ceux-ci expliquent la majorité des lenteurs réellement observées :
Causes à vérifier en premier
- Requêtes
GlideRecordnon indexées ou non bornées - Business rules sans condition
- Scripts ACL coûteux sur une vue liste
- Client scripts bavards
- Appels d'intégration sortants synchrones
- Qualifieurs de référence en dot-walking
La version manuelle ne passe pas à l'échelle
Rien de tout cela n'est compliqué une fois qu'on sait où regarder - mais « une fois qu'on sait où regarder » fait beaucoup de travail dans cette phrase. Quelqu'un doit quand même extraire le journal des transactions, lire la décomposition des temps, formuler une hypothèse et la vérifier - à chaque fois qu'un ticket « l'instance semble lente aujourd'hui » arrive. C'est du temps d'analyste réel et récurrent, et c'est réactif par nature : personne ne regarde avant que ce ne soit déjà la plainte de quelqu'un.
Ce diagnostic exécuté en continu, automatiquement
Notre propre plateforme, neo.ai, exécute exactement ce diagnostic selon un calendrier - en lisant la même décomposition des temps décrite ci-dessus, et n'escalade qu'une fois que la même cause s'est réellement répétée, pas sur un simple incident isolé. C'est l'une des sept catégories qu'elle surveille sur une instance ServiceNow.