[midPoint] Approval performance issue : slow approverRef for orgs

Frédéric Lohier frederic at lohier.org
Tue Oct 22 16:46:00 UTC 2019


Hello,



I noticed a performance issue with approvals when the approverRef
references a group of user (Org or Role) in a Midpoint instance with 20000+
users. My approvals are specified in a globalPolicyRule in the
SystemConfiguration object.



When I specifies the approverRef as below, the approval request or the
approval response each takes up to 30 seconds :



<approverRef oid="00000000-0000-0000-0000-000000000000"
relation="org:default" type="c:OrgType">



Or



<approverRef type="OrgType">

   <filter>

      <q:equal>

         <q:path>name</q:path>

         <q:value>Name of the org</q:value>

      </q:equal>

   </filter>

   <resolutionTime>run</resolutionTime>

 </approverRef>



If I reduce the number of users in Midpoint, the approval request/response
gets faster.



On the other hand, If I specify a static list of approverRef like :



<approverRef oid="00000000-0000-0000-0000-000000000000" type="c:UserType">

<approverRef oid="00000000-0000-0000-0000-000000000000" type="c:UserType">



Or a dynamic list of approvers through an approverExpression like :



<approverExpression>

    <script>


<code>midpoint.getMembersAsReferences("00000000-0000-0000-0000-000000000000")</code>

    </script>

</approverExpression>



Then , even with 20000+ users, the approval request/response takes less
than a second to be processed.



For reference, the full global policy rule :



<globalPolicyRule>

        <name>Delete user approvals</name>

        <policyConstraints>

            <modification>

                <operation>delete</operation>

            </modification>

        </policyConstraints>

        <policyActions>

            <approval>

                <approvalSchema>

                    <stage>

                        <approverRef
oid="00000000-0000-0000-0000-000000000000" relation="org:default"
type="c:OrgType">

                        <!-- Administrateurs Identités Arobas -->

                        </approverRef>

                        <automaticallyCompleted>

                            <description>If the user has the superuser
role, we automatically approve</description>

                            <script>

                                <code>

                                    if (midpoint.isDirectlyAssigned(actor,
"00000000-0000-0000-0000-000000000004")) {

                                        return 'skip';

                                    }

                                    else {

                                        return null;

                                    }

                                </code>

                            </script>

                        </automaticallyCompleted>

                    </stage>

                </approvalSchema>

            </approval>

        </policyActions>

        <focusSelector>

            <type>UserType</type>

        </focusSelector>

    </globalPolicyRule>



An excerpt of the trace:



2019-10-21 17:22:16,948 DEBUG: ##### Exit: 2255272
...repo.cache.RepositoryCache->getObject# etime: 1.311 ms

2019-10-21 17:22:16,948 TRACE: ###### retval:
systemConfiguration:00000000-0000-0000-0000-000000000001(SystemConfiguration)

2019-10-21 17:22:16,948 DEBUG: ##### Exit: 2255271
...wf.impl.engine.helpers.NotificationHelper->sendPreparedNotifications
etime: 1.755 ms

2019-10-21 17:22:16,948 TRACE: ###### retval: {}

2019-10-21 17:22:16,948 DEBUG: ##### Exit: 2255257
...wf.impl.engine.EngineInvocationContext->commit etime: 40.146 ms

2019-10-21 17:22:16,948 TRACE: ###### retval: {}

2019-10-21 17:22:16,948 DEBUG: ##### Exit: 2255157
...wf.impl.engine.WorkflowEngine->executeRequest etime: 25067.345 ms

2019-10-21 17:22:16,948 TRACE: ###### retval: {}

2019-10-21 17:22:16,948 DEBUG: ##### Exit: 2255136
...wf.impl.processors.primary.PrimaryChangeProcessor->executeStartInstructions
etime: 25146.234 ms

2019-10-21 17:22:16,948 TRACE: ###### retval: {}

2019-10-21 17:22:16,948 DEBUG: ##### Exit: 2255118
...wf.impl.processors.primary.PrimaryChangeProcessor->previewOrProcessModelInvocation
etime: 25153.706 ms

2019-10-21 17:22:16,948 TRACE: ###### retval: {}

2019-10-21 17:22:16,949 DEBUG: ##### Exit: 2255117
...wf.impl.hook.WfHook->invoke etime: 25153.876 ms

2019-10-21 17:22:16,949 TRACE: ###### retval: {}

2019-10-21 17:22:16,949 DEBUG: ##### Exit: 2254939
...model.impl.lens.Clockwork->click etime: 25198.070 ms

2019-10-21 17:22:16,949 TRACE: ###### retval: {}

2019-10-21 17:22:16,949 DEBUG: #### Entry: 2255276
...provisioning.impl.ProvisioningServiceImpl->exitConstraintsCheckerCache#

2019-10-21 17:22:16,949 TRACE: ###### args: ()

2019-10-21 17:22:16,949 DEBUG: ##### Exit: 2255276
...provisioning.impl.ProvisioningServiceImpl->exitConstraintsCheckerCache#
etime: 0.012 ms

2019-10-21 17:22:16,949 TRACE: ###### retval: null

2019-10-21 17:22:16,949 DEBUG: ##### Exit: 2254935
...model.impl.lens.Clockwork->run etime: 25198.487 ms

2019-10-21 17:22:16,949 TRACE: ###### retval: {}

2019-10-21 17:22:16,949 DEBUG: ##### Exit: 2254934
...model.api.ModelService->executeChanges etime: 25198.728 ms

2019-10-21 17:22:16,949 TRACE: ###### retval: {}

2019-10-21 17:22:16,949 DEBUG: ##### Exit: 2254933
...model.impl.controller.ModelController->executeChanges# etime: 25201.841
ms
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.evolveum.com/pipermail/midpoint/attachments/20191022/d729acb0/attachment.html>


More information about the midPoint mailing list