none
Classical vs Declarative provisioning & performance impact? RRS feed

  • Question

  • Hi,

    Does anyone have actual performance statistics on the same business logic being implemented via Classic vs Declarative provisioning methods?

    My guess would be that Classic method is more efficient and has a lower performance impact (due to things like EREs, DREs, etc).

    Just looking for some actual stats, or to hear from someone who actually has experienced it.

    Thanks,

    SK

    Thursday, April 17, 2014 2:19 AM

Answers

  • Hi,

    Sorry, I don't have any performance statistics available. If possible, I always use classic provisioning methods. It is much faster, in terms of getting identity from authoritative source to its destination systems, using declarative provisioning, following synchronization run must be executed in order to provision identities:

    • FI/DI on authoritative source MA
    • DS on auth. source MA
    • E on FIM MA
    • wait for the workflows to complete
    • DI on FIM MA
    • DS on FIM MA
    • E on all target systems.

    whereas classic provisioning consists of:

    • FI/DI on authoritative source MA
    • DS on auth. source MA
    • E on all target systems.

    Again, if possible, I like to avoid running workflows in FIM Portal. Workflow applying synchronization rule may fail (though with reliable SQL server this typically is not an issue). Another thing is that, based on my experience, DS on FIM MA (creation of ERE/DRE objects in Synchronization Engine) can be quite slow.

    If you have < 5000 identities, this is really not an issue, whereas with anything more than 10.000 identities you may encounter performance problems.

    Regards, P

    • Proposed as answer by Robin Westgaard Wednesday, April 23, 2014 1:19 PM
    • Marked as answer by Shim Kwan Thursday, April 24, 2014 3:15 AM
    Monday, April 21, 2014 10:02 AM
  • Hi,

    It greatly depends on the SQL server performance hosting FIMSynchronization database. Almost certainly, you'd experience some delay, when synchronizing ERE/DRE back&forth between Portal and Synchronization Engine and processing them. Note, once EREs are applied, I don't think they have any noticable performance impact.

    As to your question: "which Run Profiles process EREs and DREs?" I'm not sure if I understand it.

    All run profiles in a way have to process ERE/DREs (FI/DI, to read them from Portal, FS/DS to apply them in Sync Engine, E to send processing results back to Portal). 

    Regards, P


    • Edited by Poulson Wednesday, April 23, 2014 8:56 AM
    • Proposed as answer by Robin Westgaard Wednesday, April 23, 2014 1:19 PM
    • Marked as answer by Shim Kwan Thursday, April 24, 2014 3:15 AM
    Wednesday, April 23, 2014 8:55 AM
  • Expected Rule Entries (EREs) are objects that synchronize from the FIM Service into the Sync Engine. Detected Rule Entries (DREs) synchronize out from the Sync Engine to the FIM Service.

    Every inbound or outbound sync with the FIM MA will process EREs and DREs, but they are considered by the delta process, so if they are not changing you don't have to move that data back an forth. They do add overhead to the sync process as the delta calculations need to determine if they have changed or not. If you have large numbers of these and you need to run a full synchronization (which you will always need to account for), it can take considerable time. A full synchronization needs to process all objects (including EREs and DREs). Note that depending on your business rules you can have multiple EREs per user object.

    Note that with the latest builds of FIM you can do declarative provisioning without creating ERE objects (via Outbound Scoping Filters), so if your provisioning logic fits within the framework of scoping filters, you could have a huge performance increase going that way.

    There are lots of other considerations (other than performance) when choosing a declarative ("codeless") vs. non-declarative ("classic") architecture.

    Rex

    • Marked as answer by Shim Kwan Thursday, April 24, 2014 3:15 AM
    Thursday, April 24, 2014 12:56 AM

All replies

  • Hi,

    Sorry, I don't have any performance statistics available. If possible, I always use classic provisioning methods. It is much faster, in terms of getting identity from authoritative source to its destination systems, using declarative provisioning, following synchronization run must be executed in order to provision identities:

    • FI/DI on authoritative source MA
    • DS on auth. source MA
    • E on FIM MA
    • wait for the workflows to complete
    • DI on FIM MA
    • DS on FIM MA
    • E on all target systems.

    whereas classic provisioning consists of:

    • FI/DI on authoritative source MA
    • DS on auth. source MA
    • E on all target systems.

    Again, if possible, I like to avoid running workflows in FIM Portal. Workflow applying synchronization rule may fail (though with reliable SQL server this typically is not an issue). Another thing is that, based on my experience, DS on FIM MA (creation of ERE/DRE objects in Synchronization Engine) can be quite slow.

    If you have < 5000 identities, this is really not an issue, whereas with anything more than 10.000 identities you may encounter performance problems.

    Regards, P

    • Proposed as answer by Robin Westgaard Wednesday, April 23, 2014 1:19 PM
    • Marked as answer by Shim Kwan Thursday, April 24, 2014 3:15 AM
    Monday, April 21, 2014 10:02 AM
  • Thanks...since we are using declarative, there is something like 70,000 EREs and 65,000 DREs for our 15,000 users and 5,000 groups. Would these excessive numbers of EREs and DREs have an impact on the time it takes to run some Full Syncs/Full Imports?

    Ie. if we used Classical, FIM would not need to waste time on processing EREs and DREs? Thus improving the overall Run Profile times?

    btw. which Run Profiles process EREs and DREs?

    Tuesday, April 22, 2014 9:58 PM
  • Hi,

    It greatly depends on the SQL server performance hosting FIMSynchronization database. Almost certainly, you'd experience some delay, when synchronizing ERE/DRE back&forth between Portal and Synchronization Engine and processing them. Note, once EREs are applied, I don't think they have any noticable performance impact.

    As to your question: "which Run Profiles process EREs and DREs?" I'm not sure if I understand it.

    All run profiles in a way have to process ERE/DREs (FI/DI, to read them from Portal, FS/DS to apply them in Sync Engine, E to send processing results back to Portal). 

    Regards, P


    • Edited by Poulson Wednesday, April 23, 2014 8:56 AM
    • Proposed as answer by Robin Westgaard Wednesday, April 23, 2014 1:19 PM
    • Marked as answer by Shim Kwan Thursday, April 24, 2014 3:15 AM
    Wednesday, April 23, 2014 8:55 AM
  • Expected Rule Entries (EREs) are objects that synchronize from the FIM Service into the Sync Engine. Detected Rule Entries (DREs) synchronize out from the Sync Engine to the FIM Service.

    Every inbound or outbound sync with the FIM MA will process EREs and DREs, but they are considered by the delta process, so if they are not changing you don't have to move that data back an forth. They do add overhead to the sync process as the delta calculations need to determine if they have changed or not. If you have large numbers of these and you need to run a full synchronization (which you will always need to account for), it can take considerable time. A full synchronization needs to process all objects (including EREs and DREs). Note that depending on your business rules you can have multiple EREs per user object.

    Note that with the latest builds of FIM you can do declarative provisioning without creating ERE objects (via Outbound Scoping Filters), so if your provisioning logic fits within the framework of scoping filters, you could have a huge performance increase going that way.

    There are lots of other considerations (other than performance) when choosing a declarative ("codeless") vs. non-declarative ("classic") architecture.

    Rex

    • Marked as answer by Shim Kwan Thursday, April 24, 2014 3:15 AM
    Thursday, April 24, 2014 12:56 AM
  • thank you guys.
    Thursday, April 24, 2014 3:15 AM