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).

...

Gebruik

Voordat je een prestatieanalyse start, moet je een use case hebben. Wanneer een klant opmerkt dat "het systeem traag is", kun je de omgeving openen en rondklikken en merken dat dit niet het geval is (tenzij de server traag is, in welk geval je waarschijnlijk niets kunt doen).

Als een klant een prestatieprobleem meldt, zorg er dan voor dat hij zoveel mogelijk informatie geeft:

• Welk proces is langzaam?

• Welke stappen neem je?

• In welke browser doe je dit?

• Hoe is je internetverbinding?

In het verleden was de meest effectieve manier om een case te verzamelen om gebruikers de acties die ze uitvoerden te laten opnemen en die film op te sturen. Op die manier kun je gemakkelijker achterhalen welke stappen er worden genomen. Maar soms is een beschrijving ook voldoende.

De reden waarom een use case zo belangrijk is, is dat het je in staat stelt om een analyse uit te voeren en je bevindingen te rapporteren. Met behulp van het proces en de hulpmiddelen die op deze pagina worden beschreven, zou je de klant een overzicht moeten kunnen geven van hoe lang het duurde voordat je wijzigingen aanbracht en hoe lang het daarna duurde (inclusief een beschrijving van wat er is geoptimaliseerd). Dat geeft de klant meer vertrouwen in het werk dan wanneer je ze in het ongewisse laat.

Analysestappen

Er zijn twee manieren om een analyse te benaderen: bottom-up of top-down. Met betrekking tot prestaties vind je hieronder een beschrijving van deze twee benaderingen.

Ondersteboven

Met een bottom-up analyse begin je heel klein. Als je bijvoorbeeld op een knop voor een werkorder drukt, moet de gebruiker meer dan 5 seconden wachten. Je zou dit als volgt aanpakken (back-up!):

• Je begint velden één voor één te verwijderen

• Vervolgens verwijder je één voor één

• Je begint scripts één voor één te deactiveren

Als je het op deze manier doet, kun je precies bepalen waar het prestatieprobleem zit. Wees je ervan bewust dat dit tijd kost. Deze aanpak is alleen mogelijk in twee situaties:

• Je hebt niet veel factoren die de prestaties kunnen beïnvloeden. Dus niet veel velden, includes, scripting

• Bij het debuggen van scripts moet je dit stap voor stap doen, omdat het minder tijd kost om langzaam meer logica toe te laten in een script.

Bovenaan

Top down is het "gemakkelijkst" om te doen. Hier benader je het als volgt (back-up!):

• U schakelt alle scripts uit

• U verwijdert alle velden van de pagina

• Je verwijdert alle

Als je het zo doet, kun je gemakkelijk vaststellen waar de problemen zitten. Dus als er een probleem is in de scripting, kun je dat al opmerken en in de scripting duiken. Je kunt dan de helft van de scripts inschakelen om te zien of het in die helft zit. Zo ja, dan blijf je dat doen totdat je het script vindt dat traag is. Hetzelfde geldt voor includes en velden.

Het grootste voordeel is dat de hoofdoorzaak van het prestatieprobleem snel kan worden gevonden. Dit is tijdsefficiënter.

Hybride

Als je eenmaal ervaring hebt opgedaan met zowel prestatieanalyse als Workplace, kun je kiezen voor een hybride optie tussen bottom-up en top-down. Dat betekent dat als je merkt dat een script lang duurt, je niet elk script hoeft uit te schakelen. Of als je de klant al kent, weet je misschien dat ze veel klantspecifieke velden hebben en dat je in dat deel van het systeem moet kijken. Maar bij het analyseren van scripts zul je waarschijnlijk merken dat je alleen al op basis van de naam van het script weet in welk script er mogelijk query's zijn die traag zijn.

Gereedschap

Netwerkfuncties in de belangrijkste browsers

In de belangrijkste browsers (Chrome, Edge, Firefox) is een netwerkanalyse beschikbaar. Daar kun je zien hoe lang het duurt om de benodigde gegevens te downloaden. Hoe gebruik je dit:

• Open de ontwikkelaarstools. Meestal wordt dit gedaan met Ctrl + Shift + I

• Klik op het tabblad "Netwerk" (zie onderstaande afbeelding)

• Voer de volgende stappen uit om een solide analyse uit te voeren:

  • Het logboek wissen (pictogram aan de linkerkant)

  • Voer de actie uit die langzaam is

  • Als het klaar is, controleer dan de waarde in de kolom "Tijd" (voor de eerste pagina)

  • Maak een verandering

  • Voer de vorige stappen opnieuw uit

• Met behulp van deze gegevens kun je eenvoudig zien hoeveel tijd een actie kost, door gewoon de tijd ervoor en erna te vergelijken. Herhaal het bovenstaande om een duidelijk beeld te krijgen van wat je wijzigingen bijdragen aan prestatieoptimalisatie. Dit kan ook worden gebruikt wanneer je aan een klant moet rapporteren welke wijzigingen je hebt aangebracht en wat de impact daarvan was.

...

Werkplek scripting debug

Als je een prestatieanalyse uitvoert, moet je altijd het debuggen van het script inschakelen. Je kunt dit doen in het gebruikersprofiel door de waarde "Debug" op "yes" te zetten. Op die manier kun je zien welke scripts er draaien en hoe lang. Zo kun je scripts eruit pikken die te lang duren. Als vuistregel geldt: als het langer dan een paar seconden duurt om een script uit te voeren, kun je er beter naar kijken (let op: dit geldt alleen als er een prestatieprobleem is binnen een proces).

Als je eenmaal hebt vastgesteld welk script de boosdoener zou kunnen zijn, begin dan met het uitcommentariëren van regels om te zien welke logica een probleem oplevert. Zie de pagina Prestaties van scripts voor veelvoorkomende problemen met scripts. In plaats van regels uit te becommentariëren, kunt u ook tijdstempels toevoegen door de volgende logica te gebruiken:

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 takes.

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 startDat toont je de tijd inclusief milliseconden, zodat je gemakkelijk kunt zien hoe lang iets duurt. Zet dit voor en na elke logische regel die lang kan duren en je kunt gemakkelijk zien hoe lang het duurt.

Werkplek tijd debug

Workplace heeft ook ingebouwde logging waarmee je kunt zien hoe lang iets duurt. Dit kan worden gebruikt binnen een top-down benadering, hoewel in het verleden is gebleken dat door het elimineren van de standaard kandidaten (velden, includes en scripts), je vrij gemakkelijk kunt achterhalen waar een probleem zit. Maar soms, als er sprake is van trage prestaties in de Workplace software zelf, kan deze tool van pas komen.

Als je een actie uitvoert (zoals naar een object navigeren of een functie uitvoeren) kun je naar de instellingen van het object/pagina gaan en op "Debug" drukken.

...

Zodra je dat hebt gedaan, kun je naar beneden scrollen en de optie "Tijdhiërarchie" vinden. Daar kun je zien hoeveel tijd elke stap in beslag nam. Dit kan helpen bij het zoeken naar een script dat traag is, maar ook wanneer een specifieke actie in de software traag is. Gebruik het als je geen idee hebt waar je verder moet zoeken of waar je moet beginnen.

...

Grafana/Graphview/Kibana

Development keeps track performance data. They use Ontwikkeling houdt prestatiegegevens bij. Ze gebruiken 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 itvoor rapportage en Kibana voor de ruwe gegevens. Als je veel prestatieanalyses uitvoert, kan het zinvol zijn om op zijn minst een account aan te maken voor Graphview. Daar vind je verschillende rapporten die kunnen helpen bij de analyse. Er is bijvoorbeeld een overzicht van de serverbelasting. Soms is de prestatie puur gebaseerd op serveractiviteit. Als er geen duidelijk "logica"-probleem is, kan dit de oorzaak zijn. Als dat het geval is, moet de afdeling ontwikkeling erin duiken.

Maar er is ook een rapport dat de middellange tijd voor scripts op een bepaalde server laat zien. Zo kun je zien welke scripts veel tijd in beslag nemen en welke scripts mogelijk sneller kunnen worden gemaakt.

Om eerlijk te zijn moeten deze systemen niet gebruikt worden in het "dagelijkse" werk van prestatieanalyse. Je kunt ze gebruiken om te controleren of de server niet in de problemen zit, maar als dat niet het geval is, zul je in de specifieke use case van de client moeten duiken.

Microsoft Xbox video-opname

Als je op een Microsoft-systeem werkt, kun je gemakkelijk je scherm opnemen met de Windows-toets + G. Daar kun je een schermopname maken (of beter: de client een schermopname laten maken). Die kan worden gedeeld tussen de twee partijen, waardoor prestatieproblemen gemakkelijker te visualiseren zijn zonder dat je een heel proces hoeft te beschrijven. De video is misschien een beetje te groot om via e-mail te delen, maar het aanvraagsysteem van support gebruiken, of openbare tools zoals WeTransfer gebruiken, zijn misschien opties om de video te delen en te analyseren.