Introduction
Besides being a fan of ServiceNow's technologies as Mobile or Virtual Agent sometimes I have to work, and one of my favourite kind of projects is Configuration Review. In those projects we pass an automatic scan in the customer instance looking for places where documented best practices are unfollowed, and later we perform a manual investigation to look for bad smells and those things that we seasoned people identify as potential problems.
In one of my last configuration reviews I found an issue affecting the performance, and I've realized that there is not best practices created yet, so this article serves as documentation 😉
Note: All the images and code of this article had been replicated in one of my ServiceNow instances. I'm not using direct snapshots or scripts from my customers.
The Scenario
My customer, with a deeply knowledge about ServiceNow and a very good implementation, was suffering slowness in some of the main parts of the platform. The lack of fluency was pretty important, taking twenty or thirty seconds to load a list.
After open a HI ticket nothing wrong was detected and they went for a Configuration Review. The automatic phase didn't detect any abnormal finding, and actually the scoring was good, so what was going on?
The Field Styles
One thing that caught my attention was that they were able to know visually if an object was customised or not:
So I checked the Field Styles:
And I discovered that there was a Script Include function:
var FieldStylesDemo = Class.create();
FieldStylesDemo.prototype = {
initialize: function() {
},
// Given a GlideRecord, returns true if a version exists in the update set table
// ARGUMENTS:
// gr: GlideRecord.
// RETURNS:
// BOOLEAN
// USAGE:
// var customerOwned = N.isCustom(current); // true if record in sys_update_xml matches
isCustom: function(gr) {
try {
if (gs.tableExists('sys_update_version')) {
var uv = new GlideRecord('sys_update_version');
uv.addQuery('source_table', '!=', 'sys_upgrade_history');
uv.addQuery('instance_id', gr.sys_id);
uv.query();
if (uv.hasNext()) {
return true;
}
}
var ux = new GlideRecord('sys_update_xml');
return ux.get('name', gr.getTableName() + '_' + gr.sys_id);
} catch (e) {
return false;
}
},
type: 'FieldStylesDemo'
};Do you see the issue?
The Issue
Probably at the beginning there was not problem with that, and I'm sure that this is the reason why nobody thought in this functionality as the root cause of the slowness: it was there from day zero. At the beginning, being close to OOTB was key for my customer, so they introduced this feature to understand at first sight what was customized.
The issue:
- sys_update_version (+800K rows)
- sys_upgrade_history (21 rows)
- sys_update_xml (+330K rows)
Every time that a record with this functionality was presented it took about 0,5 seconds, and this capability was spread through more than 300 tables.
The Solution
Deactivating the Script Include the speed in the slowest pages was improved up to 40 times, yes, you are reading well: 40 times!!
Learned Lessons
I can share with you a few best practices:
- Press the requirements. Before making a development understand the benefit. Keep in mind that this is a recurrent work: every major upgrade is a perfect opportunity to review your modifications and understand if they still have a business reason behind them
- Do not query over system tables with potentially hundreds of thousands of rows, like sys_update_version or sys_update_xml
- Avoid using Script Includes in Field Styles, or at least avoid to query in order to set the style. The simpler, the better!
And of course, if you are stuck ask for an external fresh vision, like this community.
Have fun!
