Use case

Before starting any performance analysis, you need to have the use case. When a client remarks that “the system is slow”, you can open up the environment and click around and notice that this is not the case (unless the server is slow, in which case you most likely cannot do something).

If a client reports a performance issue, make them hand over as much information as possible:

• Which process is slow?

• What steps are you taking?

• In which browser are you doing this?

• How is your internet connection?

In the past, the most effective way of gathering a case has been to have users record the actions that they are performing and send that movie over. That way you can more easily figure out which steps are taken. But sometimes, a description is also sufficient.

The reason why a use case is so important is because it allows you to do an analysis and report back your findings. Using the process and tools described on this page, you should be able to hand the client an overview of how long it took before you made any changes and how long it takes after (including a description of what has been optimized). That will give the client more confidence in the work than when you keep them in the dark.

Analysis steps

There are two ways to approach any analysis: bottom-up or top-down. In regards to performance, below you can find a description of these two approaches.

Bottom up

With a bottom up analysis, you start really small. As an example, pressing on a button for a Workorder results in more than 5 seconds waiting for the user. You would approach this as follows (backup!):

• You start removing fields one by one

• You then remove includes one by one

• You start deactivating scripts one by one

Doing it like this results in you being able to exactly pinpoint where any performance problem might be. Be aware that this will take time. This approach is only possible in two situations:

• You don’t have a lot of factors that could influence the performance. So not a lot of fields, includes, scripting

• When debugging scripting, you need to do this step for step as it will takes less time to slowly start allowing more logic to happen in a script

Top down

Top down is the “easiest” to do. Here you approach it as follows (backup!):

• You disable all scripting

• You remove all fields from the page

• You remove all includes

Doing it like this, you can easily pinpoint where the problems are. So if there is a problem in the scripting, you can then already notice that and you can dive into the scripting. You could then enable half of the scripting to see if it’s in that half. If yes, you keep doing that until you find the script that is slow. The same goes for includes and fields.

The biggest upside is the quick homing in on the root cause of the performance problem. This will be more time efficient.

Hybrid

Once you have gained experience in both performance analysis as well as Workplace, you can choose a hybrid option between bottom up and top down. That means that if you notice a script that takes long, you don’t need to deactivate every script. Or if you know the client already, you might know that they have a lot of client specific fields and you need to look into that part of the system. But you will most likely notice this when analyzing scripts, that you will now in which script there might be queries that will be slow purely based on the name of the script.

Tools

Network tooling in main browsers

In the main browsers (Chrome, Edge, Firefox) there is the availability for a network analysis. There you can see how long it actually takes to download the necessary data. How to use this:

• Open the developer tools. Most common this is done with Ctrl + Shift + I

• Click on tab “Network” (see image below)

• To perform a solid analysis, perform the following steps:

  • Clear the log (icon on the left)

  • Perform the action that is slow

  • Once it’s done, check the value in the “Time” column (for the first page)

  • Make a change

  • Perform the previous steps again

• Using this data, you can easily see the amount of time an action takes, just compare the time before and after. Repeat the above to get a clear picture on what your changes contribute to performance optimization. This can also be used when you need to report to a client which changes you have made and what the impact was.

...

Workplace scripting debug

When performing a performance analysis, you should always enable the script debugging. You can do this in the user profile, setting the value “Debug” to “yes”. That way, you can see which scripts are running and for how long. It will allow you to pick out scripts which take too long. As a rule of thumb, if a script takes more than a few seconds to run, you might want to look into it (be aware: this only applies when there is a performance problem inside a process).

...

Anwendungsfall

Bevor Sie mit einer Leistungsanalyse beginnen, müssen Sie den Anwendungsfall kennen. Wenn ein Kunde bemerkt, dass "das System langsam ist", können Sie die Umgebung öffnen und herumklicken und feststellen, dass dies nicht der Fall ist (es sei denn, der Server ist langsam, in diesem Fall können Sie höchstwahrscheinlich nichts tun).

Wenn ein Kunde ein Leistungsproblem meldet, sollten Sie ihm so viele Informationen wie möglich zur Verfügung stellen:

• Welcher Prozess ist langsam?

• Welche Schritte werden Sie unternehmen?

• In welchem Browser machen Sie das?

• Wie ist Ihre Internetverbindung?

In der Vergangenheit bestand die effektivste Methode, einen Fall zu erfassen, darin, die Benutzer die von ihnen durchgeführten Aktionen aufzeichnen zu lassen und diese Filme zu senden. Auf diese Weise kann man leichter herausfinden, welche Schritte unternommen wurden. Manchmal reicht aber auch eine Beschreibung aus.

Ein Anwendungsfall ist deshalb so wichtig, weil er es Ihnen ermöglicht, eine Analyse durchzuführen und über Ihre Ergebnisse zu berichten. Mit den auf dieser Seite beschriebenen Verfahren und Werkzeugen sollten Sie in der Lage sein, dem Kunden einen Überblick darüber zu geben, wie lange es gedauert hat, bevor Sie Änderungen vorgenommen haben, und wie lange es danach gedauert hat (einschließlich einer Beschreibung dessen, was optimiert worden ist). Das wird dem Kunden mehr Vertrauen in die Arbeit geben, als wenn Sie ihn im Unklaren lassen.

Schritte der Analyse

Es gibt zwei Möglichkeiten, an eine Analyse heranzugehen: Bottom-up oder Top-down. Im Hinblick auf die Leistung finden Sie im Folgenden eine Beschreibung dieser beiden Ansätze.

Von unten nach oben

Bei einer Bottom-up-Analyse fängt man ganz klein an. Ein Beispiel: Das Drücken einer Taste für einen Arbeitsauftrag führt zu einer Wartezeit von mehr als 5 Sekunden für den Benutzer. Sie würden dies wie folgt angehen (Backup!):

• Sie fangen an, ein Feld nach dem anderen zu entfernen

• Dann entfernen Sie die Includes nacheinander

• Sie beginnen mit der Deaktivierung der Skripte, eines nach dem anderen

Wenn Sie so vorgehen, können Sie genau feststellen, wo ein Leistungsproblem liegt. Seien Sie sich bewusst, dass dies einige Zeit in Anspruch nehmen wird. Dieser Ansatz ist nur in zwei Situationen möglich:

• Es gibt nicht viele Faktoren, die die Leistung beeinflussen könnten. Also nicht viele Felder, Includes, Skripte

• Wenn Sie Skripte debuggen, müssen Sie dies Schritt für Schritt tun, da es weniger Zeit in Anspruch nimmt, wenn Sie langsam anfangen, mehr Logik in einem Skript zuzulassen

Von oben nach unten

Von oben nach unten ist am "einfachsten" zu machen. Hier gehen Sie wie folgt vor (Sicherung!):

• Sie deaktivieren alle Skripte

• Sie entfernen alle Felder auf der Seite

• Sie entfernen alle Includes

Auf diese Weise können Sie leicht feststellen, wo die Probleme liegen. Wenn es also ein Problem in der Skripterstellung gibt, können Sie das bereits erkennen und in die Skripterstellung eintauchen. Sie könnten dann die Hälfte der Skripte aktivieren, um zu sehen, ob das Problem in dieser Hälfte liegt. Wenn ja, machen Sie das so lange, bis Sie das Skript gefunden haben, das langsam ist. Das Gleiche gilt für Includes und Felder.

Der größte Vorteil besteht darin, dass die Ursache für das Leistungsproblem schnell gefunden wird. Dies ist zeitsparender.

Hybride

Sobald Sie sowohl in der Leistungsanalyse als auch im Workplace Erfahrung gesammelt haben, können Sie eine Mischform zwischen Bottom-up und Top-down wählen. Das heißt, wenn Ihnen ein Skript auffällt, das viel Zeit in Anspruch nimmt, müssen Sie nicht jedes Skript deaktivieren. Oder wenn Sie den Kunden bereits kennen, wissen Sie vielleicht, dass er viele kundenspezifische Felder hat und Sie sich diesen Teil des Systems ansehen müssen. Bei der Analyse von Skripten werden Sie aber wahrscheinlich feststellen, dass Sie anhand des Skriptnamens erkennen können, in welchem Skript es langsame Abfragen gibt.

Werkzeuge

Netzwerk-Werkzeuge in den wichtigsten Browsern

In den wichtigsten Browsern (Chrome, Edge, Firefox) gibt es die Möglichkeit einer Netzwerkanalyse. Dort können Sie sehen, wie lange es tatsächlich dauert, die erforderlichen Daten herunterzuladen. Wie man das benutzt:

• Öffnen Sie die Entwicklertools. Meistens wird dies mit Strg + Umschalt + I gemacht

• Klicken Sie auf die Registerkarte "Netzwerk" (siehe Abbildung unten)

• Um eine solide Analyse durchzuführen, gehen Sie wie folgt vor:

  • Löschen des Protokolls (Symbol links)

  • Ausführen der langsamen Aktion

  • Überprüfen Sie anschließend den Wert in der Spalte "Zeit" (für die erste Seite)

  • Eine Veränderung vornehmen

  • Führen Sie die vorherigen Schritte erneut durch

• Anhand dieser Daten können Sie leicht erkennen, wie viel Zeit eine Aktion in Anspruch nimmt, indem Sie die Zeit davor und danach vergleichen. Wiederholen Sie die obigen Schritte, um ein klares Bild davon zu erhalten, was Ihre Änderungen zur Leistungsoptimierung beitragen. Dies kann auch verwendet werden, wenn Sie einem Kunden berichten müssen, welche Änderungen Sie vorgenommen haben und welche Auswirkungen diese hatten.

...

Workplace Skript-Fehlerbehebung

Wenn Sie eine Leistungsanalyse durchführen, sollten Sie immer das Debugging des Skripts aktivieren. Sie können dies im Benutzerprofil tun, indem Sie den Wert "Debug" auf "ja" setzen. Auf diese Weise können Sie sehen, welche Skripte wie lange laufen. So können Sie Skripte herausfiltern, die zu lange brauchen. Als Faustregel gilt: Wenn ein Skript mehr als ein paar Sekunden für die Ausführung benötigt, sollten Sie es überprüfen (Achtung: Dies gilt nur, wenn es ein Leistungsproblem innerhalb eines Prozesses gibt).

Sobald Sie herausgefunden haben, welches Skript der Übeltäter sein könnte, kommentieren Sie Zeilen aus, um zu sehen, welche Logik zu einem Problem führt. Auf der Seite über die Leistungsfähigkeit von Skripten finden Sie Informationen über häufige Probleme bei der Skripterstellung. Anstatt Zeilen auszukommentieren, können Sie auch Zeitstempel hinzufügen, indem Sie die folgende Logik verwenden:

echo "timestamp: " + toString(now,"HH:mm:ss'.'S")

That will show you the time including milliseconds, so you can easily see how long something takes. Put this before and after any logic line that might take a long time and you can easily see how long it takesDas zeigt Ihnen die Zeit einschließlich Millisekunden an, so dass Sie leicht erkennen können, wie lange etwas dauert. Setzen Sie dies vor und nach jeder Logikzeile ein, die lange dauern könnte, und Sie können leicht sehen, wie lange es dauert.

Workplace time debug

Workplace also has built-in logging with which you can see how long something takes. This can be used within a top down approach, although in the past it has been shown that by eliminating the default candidates (fields, includes and scripts), you can quite easily retrieve where a problem is. But sometimes, when there is slow performance inside the Workplace software itself, this tool can come in handy.

When performing an action (like navigating to an object or performing a function) you can go to the settings of the object/page and press on “Debug”.

...

Once you do that, you can scroll down and find the include “Time hierarchy”. There you can see how much time each step took. This might help in the search for a script that is slow, but also when a specific action inside the software is slow. Use it when you have no clue where to search next or where to startverfügt auch über eine integrierte Protokollierung, mit der Sie sehen können, wie lange etwas dauert. Dies kann im Rahmen eines Top-Down-Ansatzes verwendet werden, obwohl sich in der Vergangenheit gezeigt hat, dass man durch Eliminierung der Standardkandidaten (Felder, Includes und Skripte) recht einfach herausfinden kann, wo ein Problem liegt. Aber manchmal, wenn die Leistung der Workplace-Software selbst langsam ist, kann dieses Tool sehr nützlich sein.

Wenn Sie eine Aktion durchführen (z. B. zu einem Objekt navigieren oder eine Funktion ausführen), können Sie zu den Einstellungen des Objekts/der Seite gehen und auf "Debug" klicken.

...

Wenn Sie das getan haben, können Sie nach unten scrollen und den Eintrag "Zeithierarchie" finden. Dort können Sie sehen, wie viel Zeit jeder Schritt benötigt hat. Dies kann bei der Suche nach einem langsamen Skript helfen, aber auch, wenn eine bestimmte Aktion innerhalb der Software langsam ist. Verwenden Sie es, wenn Sie nicht wissen, wo Sie als Nächstes suchen oder wo Sie anfangen sollen.

...

Grafana/Graphview/Kibana

Development keeps track performance data. They use Die Entwicklung verfolgt die Leistungsdaten. Sie verwenden Grafana/Graphview for reporting and Kibana for the raw data. If you do a lot of performance analysis, it might make sense to get an account for at least Graphview. There you can find several reports that might help in the analysis. For example, there is an overview of the server load. Sometimes, the performance is purely based on server activity. If there is no clear “logic”-issue, this could be the cause. If that is the case, development would need to dive in.

But there is also a report which shows the medium time for scripts on a certain server. That way you can see which scripts take a long time and which could possibly be revised to be quicker.

To be honest, these systems should not be used in the “daily” work of performance analysis. You can use them to verify that the server isn’t in trouble, but if that isn’t the case, you will need to dive into the specific use case of the client.

Microsoft Xbox video recording

When you work on a Microsoft system, you can easily record your screen using the Windows key + G. There you can make a screen recording (or better: have the client make a screen recording). That can be shared between the two parties, which makes performance problems more easily to visualize without having to describe a whole process. The video might be a bit too big to share over e-mail, but using the request system from support, or using public tools like WeTransfer might be options to share the video and analyze itfür die Berichterstattung und Kibana für die Rohdaten. Wenn Sie viele Performance-Analysen durchführen, könnte es sinnvoll sein, zumindest ein Konto für Graphview zu erstellen. Dort finden Sie verschiedene Berichte, die bei der Analyse helfen können. Zum Beispiel gibt es eine Übersicht über die Serverauslastung. Manchmal ist die Leistung rein auf die Serveraktivität zurückzuführen. Wenn es kein eindeutiges "Logik"-Problem gibt, könnte dies die Ursache sein. Ist dies der Fall, muss die Entwicklung eingreifen.

Es gibt aber auch einen Bericht, der die mittlere Zeit für Skripte auf einem bestimmten Server anzeigt. Auf diese Weise können Sie sehen, welche Skripte viel Zeit benötigen und welche möglicherweise überarbeitet werden könnten, um schneller zu sein.

Um ehrlich zu sein, sollten diese Systeme nicht für die "tägliche" Arbeit der Leistungsanalyse verwendet werden. Sie können sie verwenden, um zu überprüfen, dass der Server keine Probleme hat, aber wenn das nicht der Fall ist, müssen Sie sich mit dem spezifischen Anwendungsfall des Clients befassen.

Microsoft Xbox-Videoaufzeichnung

Wenn Sie auf einem Microsoft-System arbeiten, können Sie Ihren Bildschirm ganz einfach mit der Windows-Taste + G aufzeichnen. Dort können Sie eine Bildschirmaufnahme machen (oder besser: den Client eine Bildschirmaufnahme machen lassen). Diese kann zwischen den beiden Parteien ausgetauscht werden, wodurch Leistungsprobleme leichter sichtbar gemacht werden können, ohne dass ein ganzer Prozess beschrieben werden muss. Das Video ist vielleicht etwas zu groß, um es per E-Mail weiterzugeben, aber mit dem Anfrage-System des Supports oder mit öffentlichen Tools wie WeTransfer können Sie das Video weitergeben und analysieren.