People Picker Performance based on OOTB System User Context Displayname field

  • 23 February 2017
  • 0 replies
  • 3 views

Badge +7


 

Symptoms


We have identified an issue where using the OOTB displayname property as an input for the people pickers' resolve method takes longer to resolve than using a truncated displayname in an expression.
We tested the functionality using the smo tester to see how it responds without the use of the form going straight to the smo method, and then applying the same using the control in the form.
We have identified that using the browser's network profiling that it executes 80% faster using a manipulated (expression) displayname as input for the people picker. This should be investigated by labs.
Furthermore, by only using the user's initials in parenthesis executes the resolving method of the picker even faster.
The performance does appear to be focusing on the smo call being made to SharePoint and based on the number of filters being applied (i.e. name, displayname and email). We also limited the input property to displayname only that gave us even more performance from the picker.
 

Diagnoses


2 issues here regarding the OOTB SharePoint Integration People Picker Source SMO that the picker control uses when sharepoint list/library is applified:

1) The SAMAccount field in AD that is not covered by the OOTB SharePoint Integration People Picker Source SMO but sharepoint people picker does. Our OOTB SharePoint Integration People Picker Source SMO should behaves like sharepoint people picker on SAMAccount field.
i.e. if the user was Sunny Joab (snmp as the SAMAccount), when we search with the initials (snmp) only, the result set of snmp be displayed as top match with corresponding user details following and then anything else that contains snmp in the users group

2) Due to the issue mentioned on #1, customer is using a filter when calling the SharePoint Integration People Picker Source SMO, name contains "username", this is working exactly what the customer wanted. However, if the username in the filter is short (less than 17 characters) it is returning really fast (under 1s). However, if the username is long (more than 18 characters) it takes a significant amount of time to return (10s or more). The time increases as the number of user in AD/SharePoint increases. Customer environment contains more than 17,000 AD/sharepoint users.
 

Resolution

Please submit support ticket and request for coldfix to resolve the issue.




 

0 replies

Be the first to reply!

Reply