FIM 2010 Performance Testing – Policy Objects
Policy Objects are the heart of your deployment where you will implement the business logic needed. These will also be influenced by the scenarios (credential management, group management, user management, etc.) that you deploy. As such it is no one deployment will be exactly the same as another but to help give you a data point I would like to cover a breakdown of what we are using currently in our deployment.
RC1 Out of Box vs. Sample Deployment
|
RC1 Out of Box (OOB) |
Deployed |
Sets |
71 |
96 |
MPRs |
51 |
98 |
Workflows |
12 |
58 |
Sync Rules |
0 |
80 |
Domain Configuration |
1 |
14 |
Email Templates |
13 |
24 |
So how many objects do you plan to have in your deployment? How should you think about these policy objects with relation to performance?
Things to consider:
- Sets – Every operation in the system must be evaluated for it’s impact on a given set. Some are simple transitions like someone’s building has changed, but others have cascading effects such as a manager change impacting other objects indirectly
- MPRs – MPRs have two primary uses granting rights, & triggering WFs. As you build these out you will find you may increase your number of sets to capture the various states you expect objects to transition in & out of. As these could then trigger WFs & additional work in the system, you will need to be aware of this.
In RC0 we found a problem with our ability to scale with the number of MPRs in the system & as such have done significant work to help improve this. For example beyond the above set of MPRs we ship OOB, we have added 400 additional MPRs. Similarly we are doing testing around other core system object types to ensure we can meet your needs in deployment.
In my next post I will cover scale & load, what scale we are currently using & some questions to think about for load.