Marcus Tornberg Super Contributor.
Super Contributor.
1043 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)
0 Likes
21 Replies
Marcus Tornberg Super Contributor.
Super Contributor.

Re: Identity Applications 4.7.1 performance

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
0 Likes
Knowledge Partner
Knowledge Partner

Re: Identity Applications 4.7.1 performance

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.
0 Likes
Not applicable

Re: Identity Applications 4.7.1 performance

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
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Identity Applications 4.7.1 performance

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
0 Likes
Not applicable

Re: Identity Applications 4.7.1 performance

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
0 Likes
Micro Focus Expert
Micro Focus Expert

Re: Identity Applications 4.7.1 performance

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
0 Likes
joelburke Trusted Contributor.
Trusted Contributor.

Re: Identity Applications 4.7.1 performance

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*)))
Micro Focus Expert
Micro Focus Expert

Re: Identity Applications 4.7.1 performance

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
joelburke Trusted Contributor.
Trusted Contributor.

Re: Identity Applications 4.7.1 performance

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.
0 Likes
Knowledge Partner
Knowledge Partner

Re: Identity Applications 4.7.1 performance

>> 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
Micro Focus Expert
Micro Focus Expert

Re: Identity Applications 4.7.1 performance

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
0 Likes
Knowledge Partner
Knowledge Partner

Re: Identity Applications 4.7.1 performance

On 5/13/2019 2:45 AM, Norbert Klasen wrote:
> 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.


Cool, thanks! I have not seen such a query in NDStrace. Is it updated
to show that SSS, VLV, and Proxy Auth are being used on the trace side?


0 Likes
Micro Focus Expert
Micro Focus Expert

Re: Identity Applications 4.7.1 performance

On 2019-05-13 12:41, Geoffrey Carman wrote:
>>
>> 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.

>
> Cool, thanks!  I have not seen such a query in NDStrace. Is it updated
> to show that SSS, VLV, and Proxy Auth are being used on the trace side?


Yes:


LDAP: [2019/05/13 13:35:36.961] (172.17.2.91:52400)(0x0012:0x63) Search
request:
base: "o=data"
scope:2 dereference:0 sizelimit:0 timelimit:0 attrsonly:0
filter:
"(&(|(objectClass=inetOrgPerson))(|(givenName=*michael*)(sn=*michael*)))"
attribute: "telephoneNumber"
attribute: "mail"
attribute: "ou"
attribute: "givenName"
attribute: "photo"
attribute: "sn"
attribute: "title"
attribute: "srvprvHideUser"
attribute: "srvprvHideAttributes"
attribute: "modifyTimeStamp"
attribute: "loginDisabled"
attribute: "objectClass"
LDAP: [2019/05/13 13:35:36.961] (172.17.2.91:52400)(0x0012:0x63)
nds_back_search: Search Control OID 2.16.840.1.113730.3.4.18
LDAP: [2019/05/13 13:35:36.961] (172.17.2.91:52400)(0x0012:0x63)
nds_back_search: Search Control OID 2.16.840.1.113730.3.4.2
LDAP: [2019/05/13 13:35:36.961] (172.17.2.91:52400)(0x0012:0x63)
nds_back_search: Search Control OID 1.2.840.113556.1.4.473
LDAP: [2019/05/13 13:35:36.961] (172.17.2.91:52400)(0x0012:0x63)
nds_back_search: Search Control OID 2.16.840.1.113730.3.4.9
LDAP: [2019/05/13 13:35:36.961] (172.17.2.91:52400)(0x0012:0x63)
nds_back_search: Search Control OID 2.16.840.1.113719.1.27.101.57
LDAP: [2019/05/13 13:35:36.964] (172.17.2.91:52400)(0x0012:0x63) Proxy
Authorization identity is CN=uaadmin\OU=sa\O=data
LDAP: [2019/05/13 13:35:36.964] (172.17.2.91:52400)(0x0012:0x63)
controlSortSetup: Proxy Authorization successful
LDAP: [2019/05/13 13:35:36.964] (172.17.2.91:52400)(0x0012:0x63)
controlSortSetup: Setting duplicate context for proxy authorization.
LDAP: [2019/05/13 13:35:36.964] (172.17.2.91:52400)(0x0012:0x63) Sort
setup with index "givenName+sn"


--
Norbert
0 Likes
Knowledge Partner
Knowledge Partner

Re: Identity Applications 4.7.1 performance

On 5/13/2019 7:44 AM, Norbert Klasen wrote:
> On 2019-05-13 12:41, Geoffrey Carman wrote:
>>>
>>> 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.

>>
>> Cool, thanks!  I have not seen such a query in NDStrace. Is it updated
>> to show that SSS, VLV, and Proxy Auth are being used on the trace side?

>
> Yes:
>
>

> LDAP: [2019/05/13 13:35:36.961] (172.17.2.91:52400)(0x0012:0x63) Search
> request:
>         base: "o=data"
>         scope:2  dereference:0  sizelimit:0  timelimit:0  attrsonly:0
>         filter:
> "(&(|(objectClass=inetOrgPerson))(|(givenName=*michael*)(sn=*michael*)))"
>         attribute: "telephoneNumber"
>         attribute: "mail"
>         attribute: "ou"
>         attribute: "givenName"
>         attribute: "photo"
>         attribute: "sn"
>         attribute: "title"
>         attribute: "srvprvHideUser"
>         attribute: "srvprvHideAttributes"
>         attribute: "modifyTimeStamp"
>         attribute: "loginDisabled"
>         attribute: "objectClass"
> LDAP: [2019/05/13 13:35:36.961] (172.17.2.91:52400)(0x0012:0x63)
> nds_back_search: Search Control OID 2.16.840.1.113730.3.4.18
> LDAP: [2019/05/13 13:35:36.961] (172.17.2.91:52400)(0x0012:0x63)
> nds_back_search: Search Control OID 2.16.840.1.113730.3.4.2
> LDAP: [2019/05/13 13:35:36.961] (172.17.2.91:52400)(0x0012:0x63)
> nds_back_search: Search Control OID 1.2.840.113556.1.4.473
> LDAP: [2019/05/13 13:35:36.961] (172.17.2.91:52400)(0x0012:0x63)
> nds_back_search: Search Control OID 2.16.840.1.113730.3.4.9
> LDAP: [2019/05/13 13:35:36.961] (172.17.2.91:52400)(0x0012:0x63)
> nds_back_search: Search Control OID 2.16.840.1.113719.1.27.101.57
> LDAP: [2019/05/13 13:35:36.964] (172.17.2.91:52400)(0x0012:0x63) Proxy
> Authorization identity is CN=uaadmin\OU=sa\O=data
> LDAP: [2019/05/13 13:35:36.964] (172.17.2.91:52400)(0x0012:0x63)
> controlSortSetup: Proxy Authorization successful
> LDAP: [2019/05/13 13:35:36.964] (172.17.2.91:52400)(0x0012:0x63)
> controlSortSetup: Setting duplicate context for proxy authorization.
> LDAP: [2019/05/13 13:35:36.964] (172.17.2.91:52400)(0x0012:0x63) Sort
> setup with index "givenName+sn"
>


Coolio! Many thanks Norbert! Now if only that kind of example was added
to the docs!

I am very happy on multiple levels, since the trace shows that Sort,
Proxy Auth and Index in use are all great to know! Woo Hoo!


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.