[midPoint] Midpoint 3.4.1 Performance Issues UI and REST

Wed Nov 2 16:50:16 CET 2016

Thanks Pavol/Ivan.

That particular resource is still using a .Net Connector so that may well be the issue here.  We’re going to replace that with the OpenICF connector in the first instance to see if that resolves the issue.

Thanks

Martin Herbert
Hosting Manager / Head of IT & Hosting Services
M: +44 7862 993 003
E: martinh at tahzoo.com | W: www.tahzoo.com
A: 399 Silbury Blvd, Milton Keynes, MK9 2AH, 

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 12:32
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,

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.

[cid:image001.png at 01D23520.A9D0E170]

[cid:image002.png at 01D23520.A9D0E170]<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>

[cid:image003.png at 01D23520.A9D0E170]

From: midPoint <midpoint-bounces at lists.evolveum.com><mailto:midpoint-bounces at lists.evolveum.com> on behalf of Pavol Mederly <mederly at evolveum.com><mailto:mederly at evolveum.com>
Reply-To: midPoint General Discussion <midpoint at lists.evolveum.com><mailto:midpoint at lists.evolveum.com>
Date: Wednesday, 2 November 2016 at 11:13
To: "midpoint at lists.evolveum.com"<mailto:midpoint at lists.evolveum.com> <midpoint at lists.evolveum.com><mailto: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:

[cid:image004.png at 01D23520.A9D0E170]

2) for users (in GUI):

[cid:image005.png at 01D23520.A9D0E170]

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

[cid:image006.png at 01D23520.A9D0E170]<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>

[cid:image007.png at 01D23520.A9D0E170]

_______________________________________________

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<mailto:midPoint at lists.evolveum.com>

http://lists.evolveum.com/mailman/listinfo/midpoint

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20161102/11cddf05/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 266696 bytes
Desc: image001.png
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20161102/11cddf05/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 1294 bytes
Desc: image002.png
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20161102/11cddf05/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 1069 bytes
Desc: image003.png
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20161102/11cddf05/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.png
Type: image/png
Size: 34322 bytes
Desc: image004.png
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20161102/11cddf05/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image005.png
Type: image/png
Size: 38840 bytes
Desc: image005.png
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20161102/11cddf05/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image006.png
Type: image/png
Size: 1295 bytes
Desc: image006.png
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20161102/11cddf05/attachment-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image007.png
Type: image/png
Size: 1070 bytes
Desc: image007.png
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20161102/11cddf05/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image588000.png
Type: image/png
Size: 1293 bytes
Desc: image588000.png
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20161102/11cddf05/attachment-0007.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image546001.png
Type: image/png
Size: 1068 bytes
Desc: image546001.png
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20161102/11cddf05/attachment-0008.png>