Markus, et al,I am looking for some performance information that I haven't been able to find about FIM 2010. Mainly the things I'd like to ask are:Does FIM 2010 support multiple cores? (This was a major fault of ILM 2007, it was single threaded)Has the database structure in FIM 2010 changed from ILM 2007? ILM 2007 just uses heap tables, is FIM more normalized/relational to support better data organization in the DB and improved performance?Are there any case studies with multiple CPUs and multiple CPU speeds doing some imports/synchronizations like there was for ILM 2007 that we could look at to gauge provisioning performance?We have a large number of objects that continue to grow and unfortunately ILM 2007 and previous versions of MIIS get exponentially slower at first, then level out to be linearly slower as more managed objects and Management Agents are added. I'd like to know if (at least on paper) FIM 2010 would be an improvement.Thanks!

This is the only documentation so far that I could find with any performance related information, however it does not answer my questions.Performance TestingThe document says this:"Capacity planning information for MIIS 2003 was published in October 2005 in theMIIS 2003 Capacity Planning Guide (http://go.microsoft.com/fwlink/?LinkId=55412). The information in that guide can be applied to FIM Synchronization Service capacity planning."Can someone clarify on this? Has performance seriously not been improved since the last iteration of MIIS in 5 years?

Most of whats in FIM has not changed from a sync server perspective.Unfortunately ILM is still a single threaded application, but it is now on a 64 bit platform.Most of the peformance improvements that have been added have been focused on references throughout the revisions.I know there were a couple new features in SQL 2008 that were used, but honestly don't remember what they were.SQL is where all of your performance is, if your sql server is tuned, then will likely be the best you can do.I would suggest on FIM and on all ILM, MIIS environment that you have SQL on the same box and the named pipes protocol forced to be used.If you are using newer versions of ILM, it will not use named pipes unless it is forced through the alias. Since Named Pipes is a kernal level protocol.. It will be much faster then TCP/IP.The other recommendations are to use delta imports and delta syncs for your processes. Imports and Exports can be run at the same time, syncs can also be run at the same time, but only as long as you don't have conflicts between the syncs.HTHJoe Stepongzi - Identity Management Consultant - ILM MVP - www.microsoftIdM.com,ilmXframework.codeplex.com

Thank you for the insight Joe.This is certainly most unfortunate to hear, but i'm sure MS has its own reasoning for keeping things single-threaded.Can you expound for me please on the named pipes usage? I have experimented with this setup in the past per this article http://support.microsoft.com/kb/935396 but did not have much luck at the time in terms of a performance increase. I guess the better question to ask is, does using Named Pipes have an advantage over using only Shared Memory? SQL Server and MIIS reside on the same server, so TCP/IP has never been in question.Thanks for the recommendations, I already make use of all the delta procedures, and frankly that processing is not an issue with our schedule, but running full syncs do take an entire business day when they are required and aside from boosting the processor speed, i'm not seeing anything to help, now including FIM 2010.

Honestly it would be a really big change to make it multi- threaded and I kinow the team had to do quite a bit with all of the cool new features with FIM.Some other things that help out are indexing... Most people run it once a week, I run it once a day.Usually after I clear the run history.Do you do alot of searching in the metaverse?Are you sure you are using Name Pipes and still not TCP/IP. An easy way to check is to use SQL profiler.. Also if you just enabled Named Pipes.. there will be abit of hit of performance until a couple runs occur.. So to really judge performance you need to test this way.I have done qutie a bit of testing of this and this can improve performance quite a bit.. so if you are not using it.. switch.I usually se about a 30% improvement on just this fix... sometimes a little less, sometimes more.. really depends on how everything is coded also.What type of SQL hardware do you have? Also how is your storage configured? Joe Stepongzi - Identity Management Consultant - ILM MVP - www.microsoftIdM.com,ilmXframework.codeplex.com

Joe,I will double-check everything in regards to named pipes and tcp/ip, i agree a 30% performance improvement would be fantastic. However, I'm afraid that i'm already at that max performance with my setup. If you can answer my previous question, that would help a lot:"I guess the better question to ask is, does using Named Pipes have an advantage over using only Shared Memory? SQL Server and MIIS reside on the same server, so TCP/IP has never been in question."SQL Hardware is Win 2k3 SP2 on Xeon 5160 dual-core @ 3.00 Ghz with 32 GB RAM.Drives are configured into 2 arrays for optimal performance:Multi-disk RAID 1+0 with 10K RPM drives for the data files Multi-disk RAID 1+0 with 10K RPM drives for the log files

*bump* I've started some testing with using Named Pipes again, still gathering data from runs at this point. I have an additional question now too, i'll just repost it for reference: "I guess the better question to ask is, does using Named Pipes have an advantage over using only Shared Memory? SQL Server and MIIS reside on the same server, so TCP/IP has never been in question." and -- According to the MS article for enabling Named Pipes with SQL 2005, you need to have Shared Memory turned on. How is this prioritized and how can I be sure that Named Pipes are actually being used versus the Shared Memory? If they are both on and performance change is negligible i'm inclined to say that Shared Memory is always being used. Thanks.

have you tried logging into SQL Profiler to see which protocol is being used? This will tell you the protocol. For some reason ILM/FIM always wants to use TCP/IP, by forcing the alias, we make sure we use namedpipes. I am pretty sure the reason why ILM/FIM doesn't use Shared memory is because of the option to run on a seperate server and ease of connectivity. This is something that would have to be discussed with the product team directly as we don't have access to the source. Most likely in your current environment it is defaulting to TCP/IP even though you have shared memory configured. You can check this with SQL Profiler. As soon as you enable Named Pipes and force the alias, it will use a local named pipes connection, which is a kernal level protocol.. which will speed up the process.Joe Stepongzi - Identity Management Consultant - ILM MVP - www.microsoftIdM.com,ilmXframework.codeplex.com

Hi Joe, can you tell me what I should be looking for in the profiler when looking to check if we are using named pipes? Sorry for the dumb question, I am kind of new to sql/ilm. Exchange is my background. Looking to see way I can improve performance. Thanks Joe

Hi Joe, can you tell me what I should be looking for in the profiler when looking to check if we are using named pipes? Sorry for the dumb question, I am kind of new to sql/ilm. Exchange is my background. Looking to see way I can improve performance. Thanks Joe Hey fishmonger, when you run profiler select 'new trace'. Leave all the default options under the General tab & Events Selection tab. Click Run. As soon as the trace begins you'll see a new window starting to list a bunch of stuff, click the stop button. Then scroll to the top of the new trace window. You'll see something like 'Trace Start' followed by '-- network protocol: Named Pipes ' etc. This will tell you if you are using them or TCP/IP or another option. Back to the original posting about performance, since I never responded with our final solution, we are shortly going to test an upgrade to our processors (from 3.0Ghz to 3.5Ghz). This is the only quantifiable performance boost for MIIS that i've been able to find solidly proven in case study & research. Since we're already on named pipes/shared memory, there is no gain to be gotten from that. I expect to see a 5-10% increase from the faster processor, which will probably cut about 30 minutes off our total processing time for a full sync. Not super, but better than nothing.

Sorry for sending an email back, I tend to not get notificaitons from the site qute a bit. DirservAdmin is correct on how to check if NamePipes is running, you need to do one thing though, make sure you look for the service account that your using for MIIS/ILM/FIM. Multiple connections can be opened using different protocols. DirservAdmin, What did you do for testing methodology? You have not posted anything and say that there is no increase. I have personally tested this myself and also with a couple other people. It can be tricky to get an accurate result. Did you run Multiple Full Syncs over time? Also how often are you running full syncs? You should only need to run full syncs if you properly planned for delta syncs. And of course for new additions to your code or config. Joe Stepongzi - Identity Management Consultant - ILM MVP - www.microsoftIdM.com,ilmXframework.codeplex.com

Joe, that is correct, I've run several full sync tests with data subsets and our full data set conducted over time. Specifically I have done a load to a blank metaverse, so a full import which them provisions out to 15 MAs during sync. This would count as an initial load which I understand can take longer, but once the objects are in the MV and MA CS's (having been exported etc) I will load a large number of modifies from our data source and this full sync takes the same amount of processing time (even though presumably this is no not processing ADDs, but is evaluating every object nontheless by definition). As far as the production system running full sync, this only happens after a configuration change, ma addition, or code change. We do have a lot of custom rules in place and use multiple types of MAs which occasionally can give reason to run a full sync for data integrity purposes. Generally only delta syncs run and they do a good job, i have no performance issues there.

Did you keep track of time? One of the tests that I saw an improvement on were if you run a Full Sync with TCP/IP, run a specific amount of Full Syncs, for instance lets say 7. Were not really needing to test a full load of the db, since thats not what runs all of the time. We more or less can just test the Full Sync from your source. Next you switch the settings to the ALIAS that forces the Named Pipes Protocol to be used. You then have to recycle the services and run multiple Full Syncs.. This largely depends on the amount of memory you give to sql, because it does have to load after intial start. If you do have a chance and are able to do it again, it would be pretty cool.. I know I wish I could do it, but my time is very limited. This is where I have seen the performance on very large datasoures. 100 or so managment agents. One thing I do recommend is checking these rules that are causing you to have to run full syncs because you shouldn't have too. Also you should look how it is coded, you can gain quite a bit amount of efficiency by making sure you lose less memory, only do the calculation you need. Definitely don't make calls out to other data sources. Unless it is an XMA of course.. :) Have you also tried indexing your search attributes? Example Joins need to be indexed. Also if you are using Utils.Findmventries, make sure you indexing those also. I would also recommend doing indexing jobs on your db at least every night or whenever you have some downtime. I thought it was pretty interesting that you went with 2 Raid 10 setups.. What are the details? Also a processor mhz upgrade will help nicely, too bad we couldn't get some nice 5ghz procs.. In a couple years that should change or if you have an unlimited supply of LN2. lol Joe Stepongzi - Identity Management Consultant - ILM MVP - www.microsoftIdM.com,ilmXframework.codeplex.com

Brad Turner has just posted a 3 part blog on the performance improvements of the very latest build (4.0.3573.2): Part 1 ... documentation of the base configuration of the Hyper-V environment Part 2 ... documentation of the configuration of the VM's, the two disk configurations and baseline results in build 4.0.3531.2 (RTM w/Update 1) to use as our comparison for the new hotfix build 4.0.3573.2 Part 3 ... Brad shows how the new features can be enabled in this build to improve your initial load times by a factor of 3 Thanks Brad! This will be enormous help immediately!!Bob Bradley, www.unifysolutions.net (FIMBob?)

Brad Turner has just posted a 3 part blog on the performance improvements of the very latest build (4.0.3573.2): Part 1 ... documentation of the base configuration of the Hyper-V environment Part 2 ... documentation of the configuration of the VM's, the two disk configurations and baseline results in build 4.0.3531.2 (RTM w/Update 1) to use as our comparison for the new hotfix build 4.0.3573.2 Part 3 ... Brad shows how the new features can be enabled in this build to improve your initial load times by a factor of 3 Thanks Brad! This will be enormous help immediately!!Bob Bradley, www.unifysolutions.net (FIMBob?)

Run the SQL Server Network utility and ensure the Named Pipes protocol is ON Run %System%\cliconfg.exe on your FIM sync server Enable the Named Pipes protocol if not enabled Create an alias for your SQL instance In regedit, locate the key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\FIMSynchronizationService\Parameters Set the name of the Server parameter to the name of your alias Restart the FIM Sync Service Of course you can uninstall/reinstall the FIM sync service and specify your alias name in the wizard, but the above is quicker :)Bob Bradley, www.unifysolutions.net (FIMBob?)

How do you force FIM 2010 to use named pipes? What are the steps? thank you RickThanks Rick

Thank Bob, I did this and it is now failing to start. Is it because FIM is using an instance? Where would I include this instance?Thanks Rick

I removed the alias in the server parameter of HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\FIMSynchronizationService\Parameters and it resumed working and is now using named pipes. Thanks Rick Thanks Rick

The same principle as above should apply to the FIM service too. This old Bobby and Nima article is the best explanation I've found on SQL tuning (for FIM), which is really the first thing to look at: How to make ILM "2" scream. More recently, Brad Turner has posted a 3 part article on this subject on his blog.Bob Bradley, www.unifysolutions.net (FIMBob?)