Slow CI form loads for a single user

[Russ Hancock]

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?

[Alisa Palmieri]

This is happening to me as a developer. We realized that it was my account when someone else on the team  impersonated me. He has no problems with his own account. I diffed out our roles and I had a few more but not anything crazy.

I recently made a new account for myself, then configured it the same, logging out each time. The new account is much quicker than the old, We are currently on WDC. I had to go back to my original acct because I'm working tickets, but I do impersonate my "extra" acct just to be able to open records.

I will troubleshoot when I have the time but I do have to work as well so until I or someone comes up with something to try, I'll be in Servicenow  purgatory. 

[Russ Hancock · Accepted solution]

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.