Highlighted
Outstanding Contributor.
Outstanding Contributor.
2074 views

Identity Applications 4.7.1 performance

Hi!

I am facing some minor but annoying performance issues in Identity Applications.

For example, after authenticating to Identity Applications (works fast) and I switch to Administration / Roles or Administration / Resources, it takes between 15-20 seconds for the page to load. This causes some web browsers to display an warning similar to "the web page is not responding, do you want to reload".

The same goes if I navigate to a resource and assign it to a user, searching for users also takes between 15-20 seconds.

I have looked at the LDAP trace on the Identity Manager side, and it returns all results fast, so I think this is an Identity Application issue.

As a reference, the installation has about 17 resources, 135 roles and about 15 k users. CPU utilization is low on both nodes and there is disk space and memory available. There is no error messages in catalina.out.

There are two environments (test and production) and both display the same issue. Identity Applications is setup with a two node tomcat cluster using a HAproxy in front.

In my separate lab environment (non clustered) I do not see this kind of issues at all. I have also tried to bypass the HAproxy by using the hosts file to go directly to one node, but the result is the same.

Any ideas on how to troubleshoot it?

Best regards
Marcus
Labels (1)
26 Replies
Highlighted
Outstanding Contributor.
Outstanding Contributor.

It looks like LDAP performance is an issue searching for users:


15:43:49 780B700 -1 LDAP: DoSearch on connection 0x22790a80
15:43:49 780B700 -1 LDAP: Search request:
***base: "ou=users,o=data"
***scope:2 dereference:0 sizelimit:0 timelimit:0 attrsonly:0
***filter: "(&(|(objectClass=inetOrgPerson))(|(givenName=*john*)(sn=*john*)(cn=*john*)))"
***attribute: "fUserCategory"
***attribute: "mail"
***attribute: "ou"
***attribute: "givenName"
***attribute: "photo"
***attribute: "cn"
***attribute: "sn"
***attribute: "title"
***attribute: "fUserOrgUnitDN"
***attribute: "loginDisabled"
***attribute: "fUserAccountStatus"
***attribute: "srvprvHideUser"
***attribute: "srvprvHideAttributes"
***attribute: "modifyTimeStamp"
***attribute: "loginDisabled"
***attribute: "objectClass"
15:43:49 780B700 -1 LDAP: nds_back_search: Search Control OID 2.16.840.1.113730.3.4.18
15:43:49 780B700 -1 LDAP: nds_back_search: Search Control OID 2.16.840.1.113730.3.4.2
15:43:49 780B700 -1 LDAP: nds_back_search: Search Control OID 1.2.840.113556.1.4.473
15:43:49 780B700 -1 LDAP: nds_back_search: Search Control OID 2.16.840.1.113730.3.4.9
15:43:49 780B700 -1 LDAP: nds_back_search: Search Control OID 2.16.840.1.113719.1.27.101.57
15:43:49 780B700 -1 LDAP: Proxy Authorization identity is CN=myuser\OU=users\O=data
15:43:49 780B700 -1 LDAP: controlSortSetup: Proxy Authorization successful
15:43:49 780B700 -1 LDAP: controlSortSetup: Setting duplicate context for proxy authorization.
15:43:49 780B700 -1 LDAP: Sort setup with index "givenName+sn"
15:44:03 780B700 -1 LDAP: Sending search result entry "cn=john,ou=users,o=data" to connection 0x22790a80


This environment is setup to search for CN, Given Name and Surname when searching for users. I have added indexes to the eDirectory server:
CN+GivenName+Surname
CN+Surname+GivenName
GivenName+CN+Surname
GivenName+Surname+CN
Surname+GivenName+CN
Surname+CN+GivenName

Still, it seems to utilize givenName+sn index.

Best regards
Marcus
Highlighted
Knowledge Partner
Knowledge Partner

marcus jonsson <marcus_jonsson@no-mx.forums.microfocus.com> wrote:
>

Hi!
>
> I am facing some minor but annoying performance issues in Identity

Applications.
>
> For example, after authenticating to Identity Applications (works fast)

and I switch to Administration / Roles or Administration / Resources, it
takes between 15-20 seconds for the page to load. This causes some web
browsers to display an warning similar to "the web page is not
responding, do you want to reload".
>
> The same goes if I navigate to a resource and assign it to a user,

searching for users also takes between 15-20 seconds.
>
> I have looked at the LDAP trace on the Identity Manager side, and it

returns all results fast, so I think this is an Identity Application
issue.
>
> As a reference, the installation has about 17 resources, 135 roles and

about 15 k users. CPU utilization is low on both nodes and there is disk
space and memory available. There is no error messages in catalina.out.
>
> There are two environments (test and production) and both display the

same issue. Identity Applications is setup with a two node tomcat
cluster using a HAproxy in front.
>
> In my separate lab environment (non clustered) I do not see this kind of

issues at all. I have also tried to bypass the HAproxy by using the
hosts file to go directly to one node, but the result is the same.
>
> Any ideas on how to troubleshoot it?
>
> Best regards
> Marcus



Saw this on some places even in a single IDApps server test setup.

Alex McHugh - Knowledge Partner - Stavanger, Norway
Who are the Knowledge Partners
If you appreciate my comments, please click the Like button.
If I have resolved your issue, please click the Accept as Solution button.
Highlighted
Micro Focus Expert
Micro Focus Expert

Dear Marcus,

Its a known issue that the delay is observed when a user navigates from idmdash context to idmadmin context. There is already a bug filled for which the fix will be available for the next release

Thanks & Regards,
SivaSaran.K.R
Highlighted
Absent Member.
Absent Member.

sivasaran <sivasaran@no-mx.forums.microfocus.com> wrote:
>

Dear Marcus,
>
> Its a known issue that the delay is observed when a user navigates from

idmdash context to idmadmin context. There is already a bug filled for
which the fix will be available for the next release
>
> Thanks & Regards,
> SivaSaran.K.R



--
sivasaran
------------------------------------------------------------------------
sivasaran's Profile: https://forums.novell.com/member.php?userid=166403
View this thread: https://forums.novell.com/showthread.php?t=511165

>


Thank you SivaSaran.K.R, its good to know.

Would that also fix the people search problem that I amseeing, or "only"
navigation to idmadmin context?

--
Best regards
Marcus
Highlighted
Micro Focus Expert
Micro Focus Expert

Dear Marcus,

That would ideally fix the navigation issue from idmdash to idmadmin context

Coming to people list issue, could you try creating compound index for other attributes that are using the filter like telephone number, email etc
This may increase the performance of listing peoples in users page

Thanks & Regards,
SivaSaran.K.R
Highlighted
Micro Focus Expert
Micro Focus Expert

Hi ,

sivasaran;2495015 wrote:
There is already a bug filled for which the fix will be available for the next release


under wich bug number was this issue filed?

Norbert
--
Norbert
Highlighted
Super Contributor.
Super Contributor.

We have a ticket opened with MicroFocus about the user search issue. I think the problem is the LDAP filter is not optimized.

(&(|(objectClass=inetOrgPerson))(|(givenName=*john*)(sn=*john*)(cn=*john*)))


Putting a wildcard before and after a search string is very slow. It really should just be a wildcard after the string. I don't believe that people type the middle of a word when searching.

(&(|(objectClass=inetOrgPerson))(|(givenName=john*)(sn=john*)(cn=john*)))
Highlighted
Micro Focus Expert
Micro Focus Expert

Hi Joel,

On 2019-05-10 16:14, joelburke wrote:
>
> We have a ticket opened with MicroFocus about the user search issue. I
> think the problem is the LDAP filter is not optimized.
>
>
> Code:
> --------------------
> (&(|(objectClass=inetOrgPerson))(|(givenName=*john*)(sn=*john*)(cn=*john*)))
> --------------------
>
>
> Putting a wildcard before and after a search string is very slow. It
> really should just be a wildcard after the string. I don't believe that
> people type the middle of a word when searching.
>
>
> Code:
> --------------------
> (&(|(objectClass=inetOrgPerson))(|(givenName=john*)(sn=john*)(cn=john*)))
> --------------------


Do you see a measurable performance difference when using either filter
combined with the ProxyAuth and VLV controls that the UI use?


--
Norbert
--
Norbert
Highlighted
Super Contributor.
Super Contributor.

klasen;2499571 wrote:
Hi Joel,

On 2019-05-10 16:14, joelburke wrote:
>
> We have a ticket opened with MicroFocus about the user search issue. I
> think the problem is the LDAP filter is not optimized.
>
>
> Code:
> --------------------
> (&(|(objectClass=inetOrgPerson))(|(givenName=*john*)(sn=*john*)(cn=*john*)))
> --------------------
>
>
> Putting a wildcard before and after a search string is very slow. It
> really should just be a wildcard after the string. I don't believe that
> people type the middle of a word when searching.
>
>
> Code:
> --------------------
> (&(|(objectClass=inetOrgPerson))(|(givenName=john*)(sn=john*)(cn=john*)))
> --------------------


Do you see a measurable performance difference when using either filter
combined with the ProxyAuth and VLV controls that the UI use?


--
Norbert


I have never heard of ProxyAuth or VLV, so there is obviously something more in play here. I do know that we had to make this change to the HelpDesk Search Filter in SSPR and it sped up the search. I also tried creating a compound index and it did not speed up the search.
Highlighted
Knowledge Partner
Knowledge Partner

>> We have a ticket opened with MicroFocus about the user search issue. I
>> think the problem is the LDAP filter is not optimized.
>>
>> Code:
>> --------------------
>>
>> (&(|(objectClass=inetOrgPerson))(|(givenName=*john*)(sn=*john*)(cn=*john*)))
>>
>> Putting a wildcard before and after a search string is very slow. It
>> really should just be a wildcard after the string. I don't believe that
>> people type the middle of a word when searching.
>>
>>
>> Code:
>> --------------------
>>
>> (&(|(objectClass=inetOrgPerson))(|(givenName=john*)(sn=john*)(cn=john*)))
>> --------------------

>
> Do you see a measurable performance difference when using either filter
> combined with the ProxyAuth and VLV controls that the UI use?


Did UA switch away from the NMAS SAML method to LDAP Proxy Auth? Is
that official? Cool. Now have to learn how that works, and how to
troubleshoot it when it stops working. 🙂 Be so nice if they actually
documented this stuff.


0 Likes
Highlighted
Micro Focus Expert
Micro Focus Expert

On 2019-05-10 19:40, Geoffrey Carman wrote:
>>> We have a ticket opened with MicroFocus about the user search issue. I
>>> think the problem is the LDAP filter is not optimized.
>>>
>>> Code:
>>> --------------------
>>> (&(|(objectClass=inetOrgPerson))(|(givenName=*john*)(sn=*john*)(cn=*john*)))
>>>
>>> Putting a wildcard before and after a search string is very slow. It
>>> really should just be a wildcard after the string. I don't believe that
>>> people type the middle of a word when searching.
>>>
>>>
>>> Code:
>>> --------------------
>>> (&(|(objectClass=inetOrgPerson))(|(givenName=john*)(sn=john*)(cn=john*)))
>>>
>>> --------------------

>>
>> Do you see a measurable performance difference when using either
>> filter combined with the ProxyAuth and VLV controls that the UI use?

>
> Did UA switch away from the NMAS SAML method to LDAP Proxy Auth?  Is
> that official?  Cool.  Now have to learn how that works, and how to
> troubleshoot it when it stops working.  :)  Be so nice if they actually
> documented this stuff.


You can use a search like this to simulate /idmdash/#/users:

ldapsearch -ZZ -x -D cn=uaproxy,ou=sa,o=system -w ${ADM_PASSWD}
"(&(|(objectClass=inetOrgPerson))(|(fullname=*${QUERY}*)(cn=*${QUERY}*)))"
-e manageDSAit -e '!authzid=u:CN=user001,OU=users,OU=data' -E
sss=givenname/sn -E 2.16.840.1.113719.1.27.101.57 -E vlv=10/10/0/10

“2.16.840.1.113719.1.27.101.57” is CONTROL_REQ_DISABLE_COUNT.

For this to work you need to have a compound index with all the
attributes from the server side sort (sss) control plus the ones from
the filter - in this order. The order of the attributes in the index is
important because eDirectory will return the search results based on
their position in the index.

--
Norbert
--
Norbert
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.