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.

Open

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:

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

Open

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

Ontwikkeling houdt prestatiegegevens bij. Ze gebruiken Grafana/Graphview voor 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.