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).
Once you have pinpointed which script could be a culprit, start commenting out lines to see which logic results in a problem. See the performance page on scripting for common problems in scripting. Instead of commenting out lines, you could also add timestamps by using the following logic:
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 start.
Grafana/Graphview/Kibana
Development keeps track performance data. They use 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 it.