[midPoint] Midpoint 3.4.1 Performance Issues UI and REST
Ivan Noris
ivan.noris at evolveum.com
Wed Nov 2 13:48:37 CET 2016
Hi,
my "hint" works only for associationTargetSearch, in which case it's
like this:
... (role definition) ...
<association>
<ref>ri:adGroups</ref>
<outbound>
<strength>strong</strength>
<source>
<path>$configuration/extension/customerEnvironment</path>
<!-- System Configuration custom attribute; DEV, TEST or
PROD -->
</source>
<expression>
<associationTargetSearch>
<filter>
<q:equal>
<q:path>
declare namespace
icfs="http://midpoint.evolveum.com/xml/ns/public/connector/icf-1/resource-schema-3";
declare namespace
ri="http://midpoint.evolveum.com/xml/ns/public/resource/instance-3";
*attributes/icfs:name*
</q:path>
<expression>
<script>
<code>
cuEnv = ''
if (!basic.isEmpty(customerEnvironment)) {
cuEnv = basic.lc(customerEnvironment) // simplified for example
brevity; the goal is to know the AD suffix
}
return 'CN=GS-Foo-Admins-Bar' + ',OU=Groups,DC=' + cuEnv
+',DC=example,DC=com'
}
</code>
</script>
</expression>
</q:equal>
</filter>
*<searchStrategy>onResourceIfNeeded</searchStrategy>*
<!-- Will search in repository first, then on
resource -->
<!-- Repository Shadow contains only icfs:name (DN),
NOT samAccountName! -->
</associationTargetSearch>
</expression>
</outbound>
</association>
...
The association will try to lookup the group name (DN - icfs:name - this
is the old .NET connector) in repository (in Shadow objects). If it
cannot be found, midPoint will fetch the group information from AD (and
create Shadow).
The following requests to put account to the same group will not need to
connect to AD just to read that group.
In my setup this significantly increases the performance, because before
I was using sAMAccountName for group searching. Which is not stored in
Shadow and requires lookup in AD.
AFAIK the group reading time depends on the number of its members; very
big groups are slow to read back to midPoint. Could this be your case?
Ivan
On 11/02/2016 01:32 PM, Pavol Mederly wrote:
>
> Hello Martin,
>
> very well. So it seems that midPoint does 63 GET operations and 1
> SEARCH operation on AD group(s), taking approx. 52 seconds in total.
> This might be because of what Ivan said. I think you could try to
> replace these search-on-resource things by something more efficient,
> but I'm not an expert in this area. Maybe Ivan or someone other would
> know better.
>
> Best regards,
>
> Pavol Mederly
> Software developer
> evolveum.com
> On 02.11.2016 13:22, Martin Herbert wrote:
>>
>> Hi Pavol,
>>
>>
>>
>> I’ve increased the size of the servers which has reduced that time
>> somewhat, although the same account still takes over a minute to
>> reconcile, see details of the task below.
>>
>>
>>
>>
>>
>>
>> <http://www.tahzoo.com>
>> Martin Herbert
>> Hosting Manager / Head of IT & Hosting Services
>>
>> M: *+44 7862 993 003* <tel:+44%207862%20993%20003>
>>
>> E: *martinh at tahzoo.com* <mailto:martinh at tahzoo.com> | W:
>> *www.tahzoo.com* <http://www.tahzoo.com>
>>
>> A: *399 Silbury Blvd, Milton Keynes, MK9 2AH, *
>> <https://www.google.com/maps/place/399+Silbury+Blvd,+Milton+Keynes+MK9+2AH,+UK/@52.0414531,-0.7670066,17z/data=%213m1%214b1%214m5%213m4%211s0x4877aa98b50bb921:0xef39de0bd21f30c6%218m2%213d52.0414531%214d-0.7648179>
>>
>>
>>
>> *From: *midPoint <midpoint-bounces at lists.evolveum.com> on behalf of
>> Pavol Mederly <mederly at evolveum.com>
>> *Reply-To: *midPoint General Discussion <midpoint at lists.evolveum.com>
>> *Date: *Wednesday, 2 November 2016 at 11:13
>> *To: *"midpoint at lists.evolveum.com" <midpoint at lists.evolveum.com>
>> *Subject: *Re: [midPoint] Midpoint 3.4.1 Performance Issues UI and REST
>>
>>
>>
>> Hello Martin,
>>
>> 5 minutes is really very long time.
>>
>> In order to diagnose such problems we've implemented some statistics
>> within GUI and within tasks. Although not ideal, these indicate how
>> much time is spent in "external code", namely during resource
>> operations, mapping evaluation, and notifications.
>>
>> It would be perhaps helpful if you could look at these numbers in
>> your particular case or even share them here.
>>
>> I mean something like this:
>>
>> 1) for tasks:
>>
>> 2) for users (in GUI):
>>
>> Pavol Mederly
>> Software developer
>> evolveum.com
>>
>> On 02.11.2016 11:53, Martin Herbert wrote:
>>
>> Hi Guys,
>>
>>
>>
>> We’ve constantly been suffering with performance issues on our
>> Midpoint environment. The setup includes a cluster of 2 servers
>> with around 10,000 objects. Although user account modifications
>> are fairly quick when it comes to a small number of assignments
>> (1 or 2 maximum), there is a significant performance issue with a
>> larger amount of assignments. Testing my own account during
>> reconciliation which has 42 assignments and 2 projections to
>> different AD resources which can take up to 5 minutes before
>> completion.
>>
>>
>>
>> From an integration standpoint for these two projections, one of
>> the AD servers utilises the .Net Connector which is still slow,
>> but much quicker than the OpenICF integration on the other
>> projection.
>>
>>
>>
>> We also have a password tool that integrates with the REST
>> services for Midpoint, the same issue also applies here. The
>> more assignments that are on an account, the longer it takes for
>> a password change to occur. And in a number of cases even
>> timeouts for a given account.
>>
>>
>>
>> The major pain point is the password changes, is there no way
>> password changes can be done without removing and re-adding all
>> assignments for each given account?
>>
>>
>>
>> Overall performance also seems to be an issue in some browsers as
>> well (Firefox for example). Is there a list of supported
>> browsers available?
>>
>>
>>
>> Thanks
>>
>>
>>
>> <http://www.tahzoo.com>
>>
>>
>>
>> *Martin Herbert*
>>
>> *Hosting Manager / Head of IT & Hosting Services*
>>
>> *M: *
>>
>>
>>
>> *+44 7862 993 003* <tel:+44%207862%20993%20003>
>>
>> *E: *
>>
>>
>>
>> *martinh at tahzoo.com* <mailto:martinh at tahzoo.com>
>>
>>
>>
>> |
>>
>>
>>
>> *W: *
>>
>>
>>
>> *www.tahzoo.com* <http://www.tahzoo.com>
>>
>> *A: *
>>
>>
>>
>> *399 Silbury Blvd, Milton Keynes, MK9 2AH, *
>> <https://www.google.com/maps/place/399+Silbury+Blvd,+Milton+Keynes+MK9+2AH,+UK/@52.0414531,-0.7670066,17z/data=%213m1%214b1%214m5%213m4%211s0x4877aa98b50bb921:0xef39de0bd21f30c6%218m2%213d52.0414531%214d-0.7648179>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>>
>> midPoint mailing list
>>
>> midPoint at lists.evolveum.com <mailto:midPoint at lists.evolveum.com>
>>
>> http://lists.evolveum.com/mailman/listinfo/midpoint
>>
>>
>>
>>
>>
>> _______________________________________________
>> midPoint mailing list
>> midPoint at lists.evolveum.com
>> http://lists.evolveum.com/mailman/listinfo/midpoint
>
>
>
> _______________________________________________
> midPoint mailing list
> midPoint at lists.evolveum.com
> http://lists.evolveum.com/mailman/listinfo/midpoint
--
Ivan Noris
Senior Identity Engineer
evolveum.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20161102/2cef9759/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 266695 bytes
Desc: not available
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20161102/2cef9759/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 1293 bytes
Desc: not available
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20161102/2cef9759/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 1068 bytes
Desc: not available
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20161102/2cef9759/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 34321 bytes
Desc: not available
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20161102/2cef9759/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 38839 bytes
Desc: not available
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20161102/2cef9759/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 1294 bytes
Desc: not available
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20161102/2cef9759/attachment-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 1069 bytes
Desc: not available
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20161102/2cef9759/attachment-0006.png>
More information about the midPoint
mailing list