Hi, I'm testing with FIM2010. When I export 22000 users to FIM (export to FIMservice-database), it takes 16 hours to add the objects. It looks like FIM does 5 objects every 10 seconds. The delta-import takes 18 hours (44000 adds, 42000 updates). The whole proces of the import from 22000 accounts from a file to Active Directory and FIM takes 2 days. Database-server:16 GB memory2 CPU. The load of the CPU's doen not come above 60%. network: 1Gbps FIM-service -server4 GB memorynetwork: 1Gbps2 CPU There is no bottleneck at the CPU's, memory or network.Does anyone know how I can speed this up? Is it a problem of the application or do we need to tune SQL? For the initial load we did the steps recommended in http://technet.microsoft.com/en-us/library/ff608274(WS.10).aspx Thanks. Johan

This is, unfortunately, to be expected. Expect some more level setting from the product group regarding this, but .5 objects/sec on the FIM MA export isn't bad actually and I've seen much worse. The biggest impact you can have on your initial load times is to alter your process for moving data between environments or even for loading your test environment: Extend/import the metaverse schema and configure your MAs Extend/import the portal schema Create/import your Inbound SR from the authoritative data sources ONLY - do not import any of your custom sets or MPR's Full Import/Sync from all of your data sources and perform your initial export and confirming import of all of your objects to the FIM Portal Create/import the remaining policy to the portal Manually execute the Temporal, Set and Group update SQL jobs Use ROPU to apply Policy retroactively (the topic of one of my TEC presentations) This method bypasses all of the Set calculation that is going on behind the scenes everytime you create or modify an object in the portal and it removes any MPR's from the equation, although importing them is ok as long as you disable them all. On a moderately configured test system (2 8GB multi-instance SQL cluster with iSCSI attached NetApp storage) I was getting .6 objects/sec exported to the FIM MA without any of the custom sets or MPR's present, just my Inbound SR. When exporting updates I can easily reach 5-6 objects/sec, Creates are the problem. The FIM MA is a single threaded beast and just won't export the next object until the pending export is confirmed and completed. The only way around this at the moment is to build your own bulk-loader using the PowerShell cmdlets. I've been able to get 2+ objects exported/sec using 9 concurrent PowerShell scripts but I haven't perfected this method yet. When ROPU kicks off it is highly multi-threaded (I've seen as many as 16 operations/sec) and will max the CPU easily on the server the FIMService db is on. A few other FYI's: TempDB Log files expand quickly, make sure you have 8GB or more pre-allocated here Expect heavy use of the FIMService log file, even in Simple recovery mode, once the Request expiration process starts running, pre-allocate at least 8GB for the Logs Best practice dictates that you should separate the I/O of your Log and Database files onto separate spindles; however, my experience so far is that FIM MA exports don't seem to care about disk I/O and rarely tax the system Some Perf Counters to keep an eye on: FIM Synchronization Service (Objects Exported/sec) Logical Disk (Avg. Disk Byes/Transfer, Avg. Disk sec/Transfer, Current Disk Queue Length, Disk Transfers/sec Brad Turner, ILM MVP - Ensynch, Inc - www.identitychaos.com

Thanks Brad! Good heads-up.Danny Alvares, Technical Solutions Architect IAM

Good info, thanks Brad. What confuses me is that CPU, ram and disk IO are all middle of the road kind of usage. There's nothing taxing going on. It seems weird. I would expect to see some resource maxed out. I have yet to optimise our load process so that we don't load policy, disable full-text, don't create dynamic sets before the data-load.