000034045 - RSA Via Lifecycle and Governance 7.0 collection runtime expectations

Document created by RSA Customer Support Employee on Jan 5, 2017•Last modified by RSA Customer Support Employee on Apr 21, 2017
Version 2Show Document
  • Comment • 0
  • View in full screen mode

Article Content

Article Number000034045
Applies ToRSA Product Set: RSA Identity Governance and Lifecycle
RSA Version/Condition: 7.0
Issue

RSA Via Lifecycle and Governance 7.0 Collection Changes


One of the goals with the RSA Via Lifecycle and Governance 7.0 collector redesign was to make the collection times easier to understand.  This does not mean that they are predictable, as the time they take is still dependent on the amount of change in the data that was collected, but the time should be consistent with the percentage of change regardless of the run.

Collection Performance Initial Collection


An initial collection is still expected to take the most time for a collector.  During this run it will need to process objects and the direct relationships requiring normalization and resolution as well as create the records in the Master tables.
 

Collection 5% Change


The expectation should be that a collection with a 5% change in the data should translate to a significant reduction in the collection time as compared to an initial, but not necessarily a 95% reduction.  There are many factors that contribute to this such as the amount of data that is collected, the time to do the delta calculations and the time for taking statistics.  These will remain somewhat consistent over time.
 

Collection 10% Change


The expectation should be that a collection with a 10% change in the data should translate to a significant reduction in the collection time as compared to an initial collection, and it should be more than a collection with a 5% change.  The time difference may not be linear in nature for the same factors mentioned previously.
 

Collection Full Refresh


The concept of a full refresh has been around for a few versions now.  With 7.0, we have changed the collection wizard to automatically trigger a full refresh with certain types of collection configuration changes.  A full refresh is similar to an initial collection in that it treats everything as New and can be done for just the Object or Relationships, or Both.  This will result in a longer collection time which should be similar to what was seen with an initial collection in a scenario where both the object and relationships are being refreshed.
 

Factors in Performance


There are some different configurations which can add some extra time to a collection.  One is custom user type attributes.  With multi attributes of this type a collection has to iterate over each one individually.  Similarly are resolution rules.  With multiple resolution rules the collection has to go through each collector one at a time.
 

Indirect Explosion


The Indirect Explosion process was introduced in the 7.0 release and it is responsible calculating all the indirect or derived entitlements for Users, Accounts, Groups, and Roles in the system.  One of the main factors that will influence the processing time is the hierarchy of the relationships.  The deeper the nesting the longer it will take to process the indirect entitlements.
 

Indirect Explosion Initial Collection


The run of an indirect explosion for an initial collection run is typically the longest as it will have to determine all the derived entitlements for all objects in the system.  This does not mean just what it collected.  For example an Entitlement Data Collector (EDC) collects entitlements for groups, but accounts are members of groups and Users have accounts so it must calculate the derived entitlements for them as well.
 

Indirect Explosion Subsequent Collection


The run of an indirect explosion for a subsequent run of a collector is typically a shorter amount of time than for an initial collection.  As stated previously, some things that can factor into the time are nested objects.  Removing an entitlement from an application role is simple, but if that application role is used by another application role and subsequently used in a group, which has multiple accounts as members then the impact becomes a littler larger.
 
Tasks

Hypothetical Collection Model


Say there is an Account Data Collector which collects 10,000 accounts and 10,000 mapped users.
If the initial collection takes ten minutes (this is the processing of the data after it has been collected), the expectation is that this is the maximum time the collector would take in any future runs.
So what happens in a subsequent collection?
  1. If there are no changes collected, the collector and indirect processing will identify that and skip the steps because there are no changes to process.  The time to process would only be what is needed to calculate the changes.
  2. There are 500 accounts added and 500 mapped users added in a run.  This collection may take three minutes, so for future runs of this collector a similarly sized change should also result in similar time to process.
  3. There are 100 accounts added and 100 mapped users added in a run.  This collection may take two minutes.  The expectation is that since it is less of a change than the 500 accounts and mapped users example, the run the time should be less; it is not necessarily linear.  Again, any subsequent run with a similarly sized change should result in a similar processing time.
  4. There are 200 accounts added and 200 mapped users added in a run.  The predictability comes in here.  The expectation is that this run will be more than the one with 100 account changes and less than the one with 500 account changes.
With the redesign of the collectors in the 7.0 release we introduced a new indirect process which is responsible for managing the indirect entitlements that are the result of direct entitlement changes from a collector.  While there are some additional variables in this processing time, it should still have the consistency of the collectors based on the amount of changes that it has to process.
Let’s use the above collection changes in this example.
  1. If there are no direct entitlement changes, this should be quick as well.  The process just needs to confirm there are no changes to process in four different areas and it will skip its processing steps and complete.
  2. With the collection of 500 accounts and 500 mapped users, this processing could take seven minutes.  The important thing here is to see the amount of indirect records that are created for these users; it is these indirects that consume the time.  If all the accounts have a similar amount and type and nesting of entitlements, then the expectation is that a similar amount of changes to process should result in a similar time.
  3. With the collection of 100 accounts and 100 mapped users, this processing time could take two minutes.  Again, if the accounts have similar entitlements to the 500 accounts and mapped user example, the time to process the indirects should be less.
  4. With the collection of 200 accounts and users, this processing time should be between two and seven minutes.  The expectation is that subsequent processing should result in a similar time.

Attachments

    Outcomes