When a user has a large number of assignments, every additional assignment added takes an increasing length of time to process

When adding an role and assignment to a user who already has a significant number of roles and assignments in place, each role and assignment added takes a longer period of time to process and return a result to the end-user.

To re-produce:

• Install a base IDM 6.5.0 with a JDBC repo (Postgres used in my testing) using the sync-with-ldap-bidirectional sample
• Add the following to the start and end of 'defaultMapping.js' to show process timing:

var start = new Date().getTime();



var end = new Date().getTime();
var time = end - start;
logger.info("defaultMappings took: " + time + "ms");

• Download the attached scripts used to perform the testing (48871 - Scripts.zip)
• Start IDM
• Create a user within IDM and modify the 'addRoleMembers.sh' script with this user's _id
• Within a terminal window run the following scripts in this order:
  • createRolesAndAssignmentsV2.sh
  • writeRoleIdToFile.sh
  • addRoleMembers.sh

While addRoleMembers.sh is running, you will see the output from cURL for each entry being added:

Processing role: Role141
{"_id":"5d9e27e2-83bf-4624-b754-2643afe1c8fb","_rev":"0","_ref":"managed/user/9c1bd995-ee2a-4648-aaae-09c21bd51ffc","_refResourceCollection":"managed/user","_refResourceId":"9c1bd995-ee2a-4648-aaae-09c21bd51ffc","_refProperties":{"_id":"5d9e27e2-83bf-4624-b754-2643afe1c8fb","_rev":"0"}}    time_namelookup:  0.004419
       time_connect:  0.004574
    time_appconnect:  0.013135
   time_pretransfer:  0.013154
      time_redirect:  0.000000
 time_starttransfer:  2.732836
                    ----------
         time_total:  2.732859

real	0m2.744s
user	0m0.009s
sys	0m0.005s

This can be correlated with the logging output added above to see the volume of time spent within the defaultMapping.js script.

Within my testing:

• On 6.5.0, ~50-60% of the time taken at a higher number of roles was within the defaultMapping.js script
• On 7.0.0 ~90% of the time taken at a higher number of roles was within the defaultMapping.js script. The non-script reduction is possibly due to OPENIDM-12527 and OPENIDM-10011.

In both cases above, the major time sink seems to be a loop around the script evaluation to perform the mergeWithTarget behaviour. This also occurs with replaceTarget to a lesser extent. This loop takes 15-20ms to occur for each role which is already in place which compounds as more roles are added.