FIM 2010 Performance Testing – Topology


Customers have very different deployment needs for their product, all of these driven based on their various business requirements.  For ourselves we have taken a two pronged approach for testing the performance of FIM 2010 in different topologies.  We typically test in what I will refer to as our Standard topology & then we do additional testing in what I will refer to as our NLB topology.

Standard Topology
This is the standard configuration we generally test in.  We look for bottlenecks & may adjust this over time if we find we need to use a difference configuration.

image

NLB Topology
This is our more complex topology intended to give us insight into how the product performs both functionally & performance wise in a more complex deployment.

image

What topology are you planning to use for your deployment?  Are there any specific situations you need to handle?

In my next post, I will talk about the hardware we are using in these topologies & cover what we are seeing for resource utilization & bottlenecks.

Comments (7)

  1. Brad Turner says:

    I do think this has the makings of a wonderful relationship – you are speaking my language sir. 🙂

    So, let’s put aside the additional deployment scenarios where the SQL backend is scaled out in one form or another – I recognize that you are focusing here on scaling out the web and web service components. In our TAP testing we attempted a non-load balanced 3-tier implementation and ultimately couldn’t get it to work due to limitations with RC0. I could see small to medium sized implementations colocating the portal and web service components together effectively removing the middle tier; howerver, I expect most enterprises to deploy your NLB topology but substituting hardware load balancers.

    The other thing your diagram obscures is the type of Portal implementation. We have been saying for the better part of a year that enterprises with existing MOSS implementations will find it difficult to accept an enterprise application deployed solely on WSS and the Windows Internal DB. I sincerely hope that there is a supportability statement out there for 1) using WSS with SQL, and 2) deploying the portal components as part of a MOSS site deployment.

    I am most interested to see how the placement of the portal and web service components affect service when geographic dispersal is factored in. My initial reaction back during the alpahs even was that the web services should be deployed according to existing AD Site topology and mimic DC placement in certain situations. It’s vitally important that the interaction with the system, be it interactively with the portal or through direct web service calls (as with the Outlook plug-in) be very responsive.

    So, I am most interested to see whether or not FIM will look more like Exchange, which centralizes very well, or AD, which typically requires a high degree of distribution.

  2. Darryl Russi says:

    Thanks Brad, my goal is to help ensure we are able to gather this type of feedback & evaluate our testing to see if there are additional tests we want to add.

    As for the type of Portal implementation, in the case of our Portal implementation these are currently using WSS & the internal Windows DB.  The support statement is still being finalized & will be published later though.  

    Would support for installing on top of MOSS suit your needs or are you looking for support of MOSS site deployment?  Of which I am not an expert on & would need to find out more information on.

    With regards to geographic dispersal, the Outlook plugin does not make WS calls, but only submits mail to Exchange, so there should be no concern there.  You will also need to consider the latency between your WS & SQL as we do a large amount of work inside the SQL layer.

  3. Brad Turner says:

    Thanks Darryl,

    In order of relevence:

    1) Support FIM on WSS w/SQL

    2) Support FIM on MOSS (always SQL)

    I think that by assuring you work in the first case, the second case is more or less assured as well and it becomes a testing formality. Deploying the existing solutions in a MOSS farm seems like it should work regardless of WIDB or SQL as well as WSS or MOSS.

    Thanks for the clarification on the Outlook plug-in, I forgot this was switched over to Exchange quite some time ago. I was flashing back to an earlier conversation we had with Craig McMurty with the early alpha.

  4. Guest says:

    Guys i have a question..

    As a conclusion, can i use MOSS 2007 with FIM 2010? or it only works with WSS?

  5. Darryl Russi says:

    MOSS 2007 is not currently supported, but they are still working to finalize the support statement for RTM.

  6. Seve says:

    Hi All,

    I got a possible requirement to  integrate FIM 2010 with MOSS 2007. is it currently supported and where can I obtain a tutorial or document which shows me the steps required to have them work together?

    My end goal is to see if user can update their user profile in MOSS and have details sinchronize with FIM 2010.

  7. Darryl Russi says:

    The sync engine in FIM supports connecting to many data sources & those that are not natively supported you can either use a drop file or an extensible MA to synchronize to those data sources.  Here are a couple resources to get you started:

    1. The TechNet forum (social.technet.microsoft.com/…/threads) for FIM 2010, which is a great place for questions like this & many of the product team monitors. Here is a thread (social.technet.microsoft.com/…/A7282867-2B7A-44FB-9722-F76B88232D8E) on FIM & SharePoint which might help.

    2. TechNet article (technet.microsoft.com/…/2008.09.insidesharepoint.aspx) on Integration SharePoint & ILM (ILM is the previous version of FIM, but the information is still applicable)

    3. MSDN documentation on creating an extensible MA for SharePoint Users (msdn.microsoft.com/…/ms696071(v=VS.85).aspx)

Skip to main content