FIM 2010 R2 Reporting Performance

FIM 2010 R2 Reporting Performance

The following section is provided as guidance on initial load times and what you might expect to see in your own environment. Because there are many variables that can influence the initial load times, these times cannot be guaranteed and rather should be used as a minimum gauge when planning your FIM 2010 R2 Reporting Deployment.

Reporting Perf

The illustration above shows the layout of the testing environment used at Microsoft. The first thing that should be done prior to doing the initial load is that requests within FIM 2010 R2 should be pruned. The reason is that there are significantly more transactions that must be processed on a request than on, say an individual user. That is, there is only 1 EMO processed on a user object where as there are 7-10 EMOs processed on a request during the initial load. If there are a significant amount of requests in FIM, this can increase the initial load time substantially.

Initial report job loads first class objects and system objects.  It can load up all the first class objects (people, groups, sets, mprs, etc) in about 16 hours. The system objects (system objects are objects tied to a request and include Requests, Approvals, Approval Responses, etc.) take additional time. This is why pruning requests is recommended prior to running the initial report job load.

The initial load using the configuration and the environment above took about 17 hours. In our environment to minimize the time to run the initial job we pruned requests down to ~25k Requests.  We projected that had we left the 1.2M requests in the FIMService database our initial job would have run for an estimated 5-7 days.


Be aware that this is not a hard and fast formula and is only an estimation. In your own environment you may experience different results. Microsoft does not guarantee that you will see the exact same performance as this is based on a variety of factors.