- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-07-2024 01:47 PM
We have a single user that is experiencing very poor performance while attempting to load CI forms (regardless of CI class). Response times for all other ServiceNow functionality for this user appears to be normal. I can duplicate the issue by impersonating the user and attempting to open any CI form, but the same CI opens very quickly for my login. The user has verified that he is also seeing the same slow responsiveness on multiple workstations both on-prem and external via a VPN connection, etc. Any ideas what may be causing this behavior?
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-20-2024 06:25 AM
Thanks everyone for the suggestions! After opening a NOW Support case, it was identified that the performance issue we were experiencing for this single user was actually due to a User Preference setting for a custom DB View (u_ci_relationships) that we have defined for the cmdb_rel_ci table. The User Preference was "u_ci_relationships.db.order.direction", and the issue only occurred when the value specifies "DESC". After identifying the problematic User Preference, I did also find several other users with that same User Preference setting that were also experiencing the slow performance while opening CI forms. To permanently resolve this issue, the NOW Support contact then applied a query rewrite at the DB level. This resolved the issue for us in all situations regardless of the User Preference settings.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-07-2024 02:03 PM
Does this user have a certain or extraordinary number or roles or group membership - one that is being evaluated for ACLs, client scripts, scripted UI policies,...? If this is replicable in a sub-prod instance, can you try removing some/all roles or groups that you or other users don't have, to remove this as a possibility? Does anything appear in the system logs, or anything in any of the 'slow...' modules in the left nav?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-07-2024 02:55 PM
Thanks @Brad Bowman , yes, this user does have a very large group membership (32) and also has 4326 roles. I was able to duplicate the issue for him on a couple of our sub-prod instances though, and after removing him from all but one group on one of our instances, I am unfortunately still seeing the issue. In the system logs, I do see some slow ACL's that were logged, but removing the user from all but one group should have fixed the issue if that was related to the problem. I am also unfortunately not finding anything suspicious in the 'slow...' modules on the left-nav.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-08-2024 06:37 AM
Be sure to log out / end impersonation after role/ACL changes before re-testing. With the remaining group and roles, are there any that you or another working user don't have, and/or roles that are not granted via a group? Do the slow ACL logs point to the ones that are suspect? Do any of the same logs appear when you view a CI? Beyond ACLs, check Client Scripts and display Business Rules on the base cmdb_ci and the extended tables for anything that might be triggering for this user/group/roles/...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-08-2024 07:55 AM
Hi @Brad Bowman , thanks for your help! I did end impersonation and re-impersonate, but the issue was still occurring with just some standard ITIL roles assigned to the user. So even though there were some slow ACL's being detected, I didn't think the ACL's were the culprit at that point. I then decided to go ahead and create a NOW Support case. The support person came back very quickly with a User Preference setting that appeared to be causing the issue. This User Preference was simply a change to the default sort order for a custom database view we have for CI Relationship records. The interesting thing is that there are 288 other users with that exact same sort-order User Preference though, and none of those users that I tried impersonating were experiencing the same performance issue. NOW Support is still investigating the root cause, so they will hopefully be able to identify some more clues soon as to why that User Preference setting would cause a performance issue for only this single user. After removing the User Preference, this user is no longer experiencing slowness while opening CI forms though, so that is good!
