Die Performance ist eine der entscheidendsten Kriterien für die Akzeptanz einer Webanwendung – Nutzer wollen schnell Ergebnisse erhalten, um in ihrem Arbeitsfluss nicht gebremst zu werden. Über die Frage, was Nutzer als schnell empfinden, liefert folgender Artikel einen guten Überblick: Usabilityblog
Wie sich dem Artikel entnehmen lässt, sollten Webanwendungen Ladezeiten von möglichst unter 2 Sekunden aufweisen, da der Nutzer mehr als 2 Sekunden als Wartezeiten empfindet. Deswegen sollten sich Architekten, Entwickler, aber auch Administratoren eine gute Performance von ServiceNow Applikationen zum Ziel haben.
Abhängig davon, wo im ServiceNow Performanceprobleme auftreten, können die Ursachen unterschiedlicher Art sein. Nachfolgend werden häufige Ursachen von langen Ladezeiten bei Listen- und Formularansichten untersucht.
Listenansichten
Laden Listenansichten langsam, kann dies mehrere Ursachen haben:
a) Der Filter
Der zugrundeliegende Filter der die Ansicht der Datensätze einschränkt, ist sehr komplex, enthält viele CONTAINS-Abfragen oder wird nicht durch einen Datenbank Index unterstützt. Sollte die Ursache tatsächlich an der Datenbank liegen, können mit Hilfe des Slow Query Logs die langsamen Datenbankabfragen identifiziert und optimiert werden.
b) Anzahl Datensätze
Umso mehr Datensätze pro Seite dargestellt werden, desto mehr Zeit benötigt der Server bei ServiceNow, die Listenansicht zu erzeugen. Der Client des Nutzers benötigt logischerweise ebenfalls mehr Zeit, die Listenansicht darzustellen. Deswegen werden in einer OOTB Instanz standardmäßig auch nur 20 Datensätze pro Seite dargestellt.
c) Anzahl und Art der Spalten
Umso mehr Spalten dargestellt werden, desto mehr Zeit wird für deren Darstellung benötigt. Richtig schlecht für die Performance ist es, wenn es sich bei den dargestellten Spalten um sogenannte Dot-Walked Fields handelt. Dabei handelt es sich um Spalten, die in einer referenzierten Tabelle liegen – die Datenbank muss somit auch die referenzierten Datensätze abfragen. Die Darstellung von Dot-Walked Fields aus verschiedenen Tabellen sollte somit vermieden werden. Meine Empfehlung dazu: Da sich die meisten Menschen nur 7 Informationseinheiten merken können (siehe dazu: Millersche Zahl ), sollten auch maximal 7 Spalten dargestellt werden.
d) Calculated Fields
Ein spezieller Feldtyp in ServiceNow stellt das Calculated Field dar. Dabei handelt sich nicht um eine richtige Spalte in der Datenbank, sondern bei jedem Abruf des betreffenden Datensatzes wird der Wert des Feldes auf Basis der hinterlegten Formel berechnet. Das heißt natürlich auch, wenn auf der abgerufenen Tabelle oder der referenzierten Tabelle (Dot-Walked Fields!) ein Calculated Field ist, dass dies für jeden abgerufenen Datensatz berechnet werden muss. Um die Auswirkung auf die Performance gering zu halten, sollte ein Calculated Field zur Berechnung ausschließlich Daten des aktuellen Datensatzes (current) verwenden – auf keinen Fall sollte ein Calculated Field Datenbankabfragen verursachen! Calculated Fields werden übrigens nicht nur bei dem Abruf von Listen- und Formularansichten neu berechnet, auch bei Datenbankabfragen, die durch Skripte verursacht werden.
e) Before Query Business Rules
Da Before Query Business Rules vor der Ausführung einer Datenbankabfrage verarbeitet werden, werden sie auch beim Aufruf von Listenansichten evaluiert und haben somit auch einen Einfluss auf die Performance von Listenansichten.
Formularansichten
Das Beheben von Performanceproblemen auf Formularen gestaltet sich deutlich schwieriger und langwieriger als auf Listenansichten. Nachfolgend typische Ursachen für Performanceeinschränkungen auf Formularen:
a) Anzahl der Felder
Mehr Felder auf einem Formular benötigen auch mehr Zeit bei der Darstellung – deshalb sollten die Anzahl der dargestellten Felder aus Gründen der Übersichtlichkeit und der Performance auf die nötigsten Informationen beschränkt werden.
b) Display Business Rules
Display Business Rules werden vor dem Aufruf von Forumlaren ausgeführt und können somit erheblich die Performance von Formularansichten beeinflussen.
c) Synchrone Serveraufrufe
Die Verwendung von synchronen Serveraufrufen sollte maximal vermieden werden – bei Smartphones und im Service Portal werden synchrone Serveraufrufe auch direkt gar nicht ausgeführt.
d) Unnötige Serveraufrufe
Nichts ist so unnötig, wie ein OnLoad Client Script, was direkt einen Serveraufruf macht, denn diese Information hätte auch mittels Display Business Rule und g_scratchpad bereits ohne weiteren Serveraufruf beim Client sein können.
e) Anzahl und Komplexität von Client Scripts und UI Policies
Client Scripts und UI Policies können erheblich die Dauer für das Rendern des Formulars auf dem Client des Nutzers beeinflussen.
f) Embedded Lists
Bei Embedded Lists handelt es sich um Listen, die direkt auf dem Formular dargestellt werden. Das kann zum Beispiel die Liste aller Incidents der Person, die den aktuellen Incident erstellt hat, sein. Statt solche Listen direkt einzubinden, sollten dafür eher Related Lists oder UI Macros verwendet werden.
g) Related Lists
Related Lists werden unter dem Formular dargestellt und stellen Listenansichten dar, in denen der aktuell geöffnete Datensatz referenziert wird. Abhängig davon, wie viele Related Lists mit wie vielen Datensätzen angezeigt werden sollen, kann dies sehr stark die Ladezeiten beeinflussen. Um diesen Einfluss zu verringern, können sowohl Administratoren (mittels System Property und globaler User Preference) und Nutzer (mittels Einstellungsmenu) einstellen, dass Related Lists asynchron nach dem Formular geladen werden sollen.