Prestaties bij implementatie
Asynchroon omvat
De eenvoudigste oplossing voor prestatieverbeteringen is om includes "asynchroon" te maken. Hierdoor gebeurt het volgende:
Workplace laadt het aangevraagde object door de gebruiker
Workplace toont het object aan de gebruiker
Zodra het laden van het object is voltooid, begint Workplace met het laden van de includes
Zodra de gegevens in een include zijn geladen, worden de gegevens gepresenteerd. Dit gebeurt voor alle includes tegelijk (dus een kleine include wordt eerder getoond dan een grote include)
Dit wordt vergeleken met het standaardgedrag:
Workplace laadt het aangevraagde object door de gebruiker
Workplace laadt alle includes die door de gebruiker aan het object zijn gekoppeld
Zodra het laden klaar is, krijgt de gebruiker alle gegevens in één keer te zien.
Ook al zal de totale prestatie op de server niet verbeteren, de PERCEIVED prestatie door de gebruiker zal wel verbeteren.
Als u wilt instellen dat includes asynchroon zijn, opent u de paginadefinitie, scrollt u naar beneden door de includes en selecteert u alles en wijzigt u de waarde voor asynchroon in "ja", of opent u de includes die u wilt wijzigen en stelt u de waarde in op "ja".
Dropdown velden
Dropdown-velden zijn een mooie manier om gebruikers een specifieke reeks waarden te presenteren. Het kan ook de prestaties ondermijnen als het filter achter het dropdown veld niet correct is. Een veelvoorkomend voorbeeld is wanneer je een klantspecifiek veld maakt dat eindigt op CodeTypeId. Als Workplace het bijbehorende CodeTypeSchema niet kan vinden en je het veld instelt om als dropdown weer te geven, zal het ALLE codetypes als mogelijke opties retourneren. Een ander voorbeeld is bij het maken van een dropdown met Contacten die afhankelijk zijn van het huidige object (bijvoorbeeld een Werkorder), maar het presenteren van dat veld in een rapport waar er geen Werkorder in de context is (omdat je op een rapport bent). De dropdown zou dan bestaan uit alle Contactpersonen.
Neem de volgende stappen bij het implementeren van een vervolgkeuzemenu:
Maak het veld aan waarmee je een object kunt selecteren (dit is het enige geval waarbij prestatieproblemen optreden)
Zorg ervoor dat het veld is ingesteld op "object selectiescherm".
Voeg indien nodig een filter toe
Navigeer naar het object of rapport en vul het veld in. Je krijgt nu het selectiescherm voor het object te zien. Voer het uit "zoals het is". Als alles goed is gegaan, krijg je de waarden te zien die je verwacht. Zo niet, dan weet je dat je een fout hebt gemaakt en kun je deze herstellen.
Zodra je het gewenste resultaat hebt, verander je het veld in "object dropdown".
Controleer bij het analyseren van een prestatieprobleem altijd de pagina op dropdowns. Controleer hoeveel waarden daarin staan. Als het om client-specifieke velden gaat, controleer dan de filters en optionele scripts waarmee de waarden worden opgehaald om te zien of daar suboptimale query's in zitten.
Grote rapporten
Deze zou vrij voor de hand moeten liggen, maar rapporten met veel resultaten hebben een negatieve invloed op de prestaties. Vooral als deze worden toegevoegd als een include aan een object. Als, om wat voor reden dan ook, een asynchrone include niet mogelijk is, overweeg dan om de filtering op deze rapporten te veranderen zodat ze een beperktere set gegevens teruggeven. Dit is vooral een functionele beslissing:
Zorg ervoor dat grote rapporten handmatig worden uitgevoerd, zodat de gebruiker weet dat het rapport lang duurt
Kijk of je de hoeveelheid gegevens op een include kunt verkleinen, want een include moet de gebruiker alleen gegevens tonen die op dat moment relevant zijn voor dat object.
Als je dashboards hebt voor gebruikers, beperk dan de hoeveelheid gegevens daarop (en maak ze asynchroon)
Scripts in rapporten
In rapporten kan scripting worden gebruikt om indien nodig complexere formules uit te voeren. Een formule zou er als volgt uit kunnen zien:
execute("MakeComplexCalculation",WorkorderReference)
Er is één nadeel: wanneer je waarden doorgeeft aan het script (in het bovenstaande geval "WorkorderReference"), worden deze doorgegeven als strings, NIET als objecten. Dat heeft dus tot gevolg dat het script een tweede query moet uitvoeren op basis van de waarde. Om een hypothetisch geval te schetsen:
Een rapport geeft 100 werkorders
Op basis van die werkorders geeft u de werkorderreferentie door aan het formulescript
Vervolgens doe je een query op de werkorderreferentie, waaruit je de waarden van de werkorder haalt en een berekende waarde retourneert
De bovenstaande situatie resulteert in 101 queries: één voor het rapport, 100 voor elke opeenvolgende regel waarvoor je de berekening maakt. Een meer performante optie is om alle benodigde waarden die u nodig hebt in het script toe te voegen aan het rapport, ze te verbergen voor het eindresultaat, maar ze door te geven aan de formule. De formuleaanroep zou er als volgt uitzien:
execute("MakeComplexCalculation",WorkorderPlannedAmount,WorkorderInvoicedAmount,WorkorderSupplierMultiplier)
In het script gebruik je dan de (string!) waarden om de nodige berekeningen te maken. Dit resulteert in 1 query voor het volledige rapport.
Klantspecifieke velden
Elke keer dat je een client-specifiek veld aanmaakt, resulteert dit in een extra database-aanroep voor elk object dat dat veld heeft. Op bepaalde momenten wordt dit een prestatie-killer (de ervaring leert dat dit bij ongeveer 80 clientspecifieke velden vrij traag wordt). Houd dus rekening met de volgende aspecten bij het maken van clientspecifieke velden (of bij het debuggen van de prestaties):
Maak klantspecifieke velden op de laagst mogelijke categorie. Dat zorgt ervoor dat de velden alleen worden gemaakt voor een specifieke subset van objecten.
Zet een klantspecifiek veld alleen op een hoger categorieniveau als meer dan 3 subcategorieën het nodig hebben OF de subcategorieën in combinatie met de hoofdcategorie een beperkte subset zijn
Bekijk de bestaande velden en kijk of je een veld kunt hergebruiken of niet
Opschonen van velden die niet meer worden gebruikt
Als er veel verschillende velden nodig zijn, overweeg dan het gebruik van een onafhankelijk object (bijv. CodeType) met een specifieke categorie om de velden op te plaatsen. Dit voorkomt onnodige velden op een specifiek object. Het kan ook resulteren in de mogelijkheid om het onafhankelijke object op een later tijdstip te maken, wat de impact op de prestaties vermindert bij het aanvankelijk maken van het object.