Warum ist Ihre ServiceNow-Instanz langsam?
„Langsam“ ist kein einzelnes Problem - es sind mehrere unterschiedliche Ebenen, die meistens niemand getrennt hat, bevor er versucht hat, sie zu beheben. So finden Sie es tatsächlich heraus.
„Langsam“ sind mindestens fünf verschiedene Probleme
Ein einzelner Seitenaufruf oder eine Transaktion durchläuft mehrere, wirklich getrennte Ebenen, und jede scheitert aus einem anderen Grund. Die falsche zu beheben, ist die häufigste Art, wie eine Performance-Untersuchung ins Leere läuft.
Client-Rendering
Zeit im Browser selbst - UI Policies, Client Scripts und das Rendern der Seite. Fühlt sich langsam an, selbst wenn der Server sofort geantwortet hat.
Netzwerk-Roundtrip
Zeit, die Anfrage und Antwort unterwegs verbringen. Oft die tatsächliche Ursache hinter „für entfernte Nutzer ist es langsam“ - Beschwerden, die vor Ort nie auftauchen.
Server-Geschäftslogik
Business Rules, Script Includes und Workflow-/Flow-Logik, die auf dem Server laufen, bevor überhaupt eine Antwort gebaut werden kann.
Datenbank
Die tatsächliche SQL-Zeit - Abfragen ohne nutzbaren Index oder eine Abfrage, die weit mehr Zeilen holt, als die Seite braucht.
Integrationen mit Drittsystemen
Ein ausgehender REST- oder SOAP-Aufruf, synchron innerhalb der Transaktion, ohne Timeout - die ganze Seite wartet auf die API eines anderen Systems.
So finden Sie es tatsächlich heraus, statt zu raten
ServiceNow erfasst das meiste davon bereits - die Diagnose braucht meist kein zusätzliches Tool.
Client Transaction Timings aktivieren
Ist dieses Plattform-Plugin aktiv, trägt jede Zeile in syslog_transaction eine echte Millisekunden-Aufschlüsselung über neun Felder - Client-Antwortzeit, Client-Netzwerkzeit, Browser-Zeit, Client-Script-Zeit, UI-Policy-Zeit auf der Client-Seite; Server-Antwortzeit, Netzwerkzeit, Business-Rule-Zeit und SQL-Zeit auf der Server-Seite. Diese eine Zeile zeigt, welche der fünf Ebenen oben tatsächlich dominiert, statt mit der Stoppuhr zu raten.
syslog_transaction direkt lesen
Auch ohne dieses Plugin trennen transaction_processing_time und business_rule_count auf derselben Tabelle „der Server war tatsächlich beschäftigt“ von „etwas ist clientseitig langsam, obwohl der Server einwandfrei geantwortet hat“.
Bei Next Experience / Workspace-Seiten sys_client_interaction prüfen
Ein einzelner Seitenaufruf kann mehrere Server-Transaktionen umfassen. Diese Tabelle liefert stattdessen das Gesamtbild der ganzen Seite - Ladezeit, Zeit bis zur Interaktivität und eine echte UI-Cache-Trefferquote, statt einer Vermutung, ob Caching überhaupt das Problem ist.
Die üblichen Verdächtigen
Ist die Ebene bekannt, erklären diese die meisten real beobachteten Fälle von Langsamkeit:
Ursachen, die zuerst geprüft werden sollten
- Unindizierte oder unbegrenzte
GlideRecord-Abfragen - Business Rules ohne Bedingung
- Teure ACL-Skripte in einer Listenansicht
- Gesprächige Client Scripts
- Synchrone ausgehende Integrationsaufrufe
- Dot-Walked Reference-Qualifier
Die manuelle Variante skaliert nicht
Nichts davon ist kompliziert, sobald man weiß, wo man suchen muss - aber „sobald man weiß, wo man suchen muss“ leistet in diesem Satz eine Menge Arbeit. Jemand muss trotzdem das Transaktionsprotokoll ziehen, die Zeit-Aufschlüsselung lesen, eine Hypothese bilden und sie verifizieren - jedes einzelne Mal, wenn ein Ticket „die Instanz fühlt sich heute langsam an“ hereinkommt. Das ist echte, wiederkehrende Analystenzeit, und von Natur aus reaktiv: Niemand schaut hin, bevor es nicht schon jemandes Beschwerde ist.
Diese Diagnose läuft kontinuierlich, automatisch
Unsere eigene Plattform, neo.ai, führt genau diese Diagnose nach Zeitplan aus - liest dieselbe oben beschriebene Zeit-Aufschlüsselung und eskaliert erst, wenn dieselbe Ursache tatsächlich wiederkehrt, nicht bei einem einzelnen Einzelfall. Das ist eine von sieben Kategorien, die sie auf einer ServiceNow-Instanz überwacht.