A recurring theme in the roles that I have held over the last decade or so in the ServiceNow ecosystem is the need to support developers and administrators in tackling performance issues experienced while operating processes which are performant out of the box, but are suffering from performance issues in their instances.
Lets take for the sake of example, incident management. The scenario which often unfolds is that there are intermittent reports that "ServiceNow is running slow" and on investigation, the "slowness" is broadly speaking related to users working with incidents.
We sit alongside the user, and guess what? It’s fine. If we are lucky, we'll stumble on something that is reproducibly slow and gives us a chance to start analysing why.
We will take a look at a bunch of obvious candidates, including network, browser. We'll look at related lists and see if we have lots, or lists returning large numbers of records.
What do we check next though when we've ruled out the obvious? Oddly, not many people I've helped in the past seem not to know about Transaction call chains, but it can be a super powerful next step. It's certainly a better option than chewing through all fields, client and server side scripts one by one and trying to guess which it might be.
So lets look at how we use it. It's incredibly simple.
First, we navigate to the record/form we are having an issue with. In our example, we open an incident.
We then search the transaction log for the transaction corresponding to hitting this page. Here it is:-
We now select the "Record call chain of next occurrence" related link action near the bottom of the form, and it creates the following new transaction call chain register record for us to complete and to save.
With the call chain register record created, I now hit the same incident URL again. And once that's loaded, I can now look at the call chain records. I order by duration, and now I know immediately where to focus my attention.
It's usually the case that the culprit is either a custom script of some sort, or it is related to data (code executing against a larger than typical data set). But regardless of the cause, you've probably just saved yourself a good chunk of time and are now looking at the objects which are causing the performance issue.
