Enabling 'Audit' checkbox on sys_dictionary for pm_project table.

[_Yash24]

Hi,

In customer environment, project workspace is taking time to load all projects. (around 20-25 seconds)

1. If I make 'Audit' checkbox to true on sys_dictionary for pm_project table, Does it give performance issue on project workspace?

2. what If I do this on field level does that make any difference on project workspace performance?

also when project has 0(zero) project tasks, its not taking much time to load but when project has more than 10 project tasks, its taking time around 20 seconds.

what could be the other reasons of project workspace slowness? 

Thanks in advance.

[Rajesh_Singh · Accepted solution]

@_Yash24 

1. Enabling the 'Audit' checkbox on the sys_dictionary for the pm_project table could potentially impact the performance of the project workspace. Auditing records all changes made to a table, increasing the amount of data stored and processed. This additional overhead might slow down the performance of certain operations, such as retrieving and displaying data on the project workspace.

2. If you enable auditing on a field level, it will still have an impact on performance. However, the impact might be less significant compared to enabling auditing for the entire table, as it will only track changes to specific fields. Nonetheless, it's essential to carefully assess whether the benefits of auditing specific fields outweigh the potential performance impact.

As for the project workspace slowness when dealing with projects that have multiple project tasks, there could be several reasons:

1. Complex or inefficient filters and queries: The project workspace might be using complex filters or queries to fetch and display project information. Examine the filters and queries to ensure they are optimized for performance.

2. Large volume of data: If there's a large volume of data associated with projects and tasks, it could impact the loading time of the project workspace. Consider implementing data archiving strategies or reducing the number of records displayed at a time to improve performance.

3. Client-side scripting or customization: Any client-side scripting or customization in the project workspace can impact its performance. Review any customizations, including client scripts or UI policies, to ensure they are efficient and not causing performance issues.

4. Server performance or resource constraints: The overall performance of the ServiceNow instance, including server resources such as CPU, memory, and network, could be impacting the loading time of the project workspace. Monitor the instance's resource usage and performance to identify any bottlenecks or resource constraints.

5. Browser performance: The client browser's performance can also impact the loading time of the project workspace. Ensure users are using a compatible and up-to-date browser and clear browser cache if necessary.

To address the performance issues, consider the following:

1. Optimize filters, queries, and scripts to reduce the amount of data fetched and processed.
2. Implement pagination to limit the number of records displayed at a time.
3. Review and optimize any client-side scripting or customization.
4. Monitor server performance and allocate additional resources if needed.
5. Ensure users are using compatible and up-to-date browsers.

[_Yash24]

@Rajesh_Singh ,
Thank you so much for detailed information and sharing project workspace slowness reasons.

I checked in the environment and I can see there is one customized "Before Query Business rule" written on sys_user table which checks the domain of current users also it executes as many times as project tasks in project.

For example: If Project has 10 project tasks then it will execute 10 times to check for the users which are present in that specific domain and My domain has 1000 users that's the reason it is taking time to load.

Can we optimize below is the code in a way that it can improve execution time?

(function executeRule(current, previous /*null when async*/ ) {

gs.log('Action : ' + gs.action.getGlideURI().toString());

if ((gs.action.getGlideURI().toString().startsWith('api/now/form/mention/record/')) || // for work notes mention
(gs.action.getGlideURI().toString().startsWith('planningconsoleprocessor.do?')) || // for old planning console
(gs.action.getGlideURI().toString().startsWith('api/now/v1/batch?api=api')) || // for new planning console
(gs.action.getGlideURI().toString().startsWith('angular.do?sysparm_type=ref_list_data')) || // for visual task board
(gs.action.getGlideURI().toString().indexOf('sysparm_nameofstack=reflist') > -1) || // for user lookup
(gs.action.getGlideURI().toString().indexOf('sysparm_modify_check=true') > -1))// for form saving
(gs.action.getGlideURI().toString().startsWith('xmlhttp.do?m2m_selected_ids=&sys_target='))) // for m2m window
{

var session = gs.getSession();
var dpSysDomain = session.getCurrentDomainID(); /* set current domain */
var grUser;
var arrUtil = new ArrayUtil();
var arrSysId = [];
var grDomain;

if (dpSysDomain != '') {
grDomain = new GlideRecord('domain');
grDomain.addQuery('sys_id', dpSysDomain);
grDomain.queryNoDomain();
if (grDomain.next()) {
var path = grDomain.getValue('sys_domain_path');
}
var grUserVisibility = new GlideRecord('sys_user_visibility');
grUserVisibility.addQuery('user.active', true);
grUserVisibility.addQuery('sys_domain', grDomain.getUniqueValue());
grUserVisibility.queryNoDomain();

while (grUserVisibility.next()) {
arrSysId.push(grUserVisibility.user.sys_id.toString());
}

grUser = new GlideRecord('sys_user');
grUser.addQuery('active', true);
grUser.addQuery('sys_domain', grDomain.getUniqueValue());
grUser.queryNoDomain();

while (grUser.next()) {
arrSysId.push(grUser.sys_id.toString());
gs.log('Check 4');
}

arrSysId = arrUtil.unique(arrSysId);
current.addEncodedQuery('sys_idIN' + arrSysId.join(','));
gs.info('<DP> sys_idIN + arrSysId.join(,) = ' + 'sys_idIN' + arrSysId.join(','));
}
} else {
grUser = new GlideRecord('sys_user');
grUser.get(gs.getUserID());
current.addQuery('sys_domain' + grUser.sys_domain);
}

})(current, previous);

[Rajesh_Singh]

@_Yash24 

The code provided can be optimized for better performance by reducing the number of GlideRecord queries and by using GlideAggregate for counting purposes.

[Yash40]

@Rajesh_Singh ,

Can I write script include for GlideRecords and call that in Business rule.
Does it make any difference in rule execution time?

Thanks in advance.