Parts of central admin are excrutiatingly slow

Question

I have a new sharepoint 2010 install, setup on two virtual machines (one a web frontend, the other sql). Virtualization is microsoft hyper-v. Both VMs have 8GB RAM and 4 cpu cores. The VM host isn't oversubscribed, so I don't think that it's slow just from being in the virtual machine.

I expect the first few page loads of the day to be excruciating slow, since I'm the only one accessing it at the moment and IIS has to fire up its application pools and such.

However, even after that is done, some parts are just SLOW.

One particular part I've noticed is always an issue is editing the user property fields in the user profile service - I see 2-5 minute load times getting to the page to edit a property, and another 2-5 minutes saving it - sometimes it just times out entirely. It's taken me all day to edit a dozen fields!

Is this part of central administration normally slow?

How do I go about finding what is causing it to be slow? While the slow pages are loading I see w3wp.exe taking up 25% cpu time (100% of one core), and around 400MB of memory.

I don't know at what layer the slowdown is happening. What diagnostics can I do to find out whether the slowdown is happening in sharepoint, IIS, the SQL server, the network, the disk subsystem, the virtual machine, etc?

Answer 1

In my experience the UPS settings pages are always slow. I remember once I was filtering users by Active Directory OUs and had to wait ~1 min for the page to finish loading every time I clicked to expand a node on a dedicated production server (the forest also had a large number of users and groups).

I don't think this is VM specific. Rather, I believe that this is being caused because the page is communicating via web services to Active Directory (though that's an educated guess). The page certainly isn't posting back between loads.

I griped about the page load time in a post about this:

User Profile Synchronization - Filter by AD OU or DN attributes

Answer 2

I found a thread here from someone who opened a microsoft support case about this exact issue. Their answer was:

Microsoft's Assessment:

"Based on a review of the configuration of the connection between SharePoint and AD , the data analysis completed to date and a separate review of the case by Microsoft Escalation engineers everything from a SharePoint to FIM to AD connection look to be in order and functioning as designed . Furthermore when an internal repro of a similar operation (Single SharePoint server and Single domain) was conducted at Microsoft a similar delay was experienced for rendering user profile pages.

Also in discussing this issue and looking at the various APIs and code involved in user profile web pages the consensus is that the particular APIs and code path being taken during the rendering of these pages is that of an administrative function to modify \ add \ Etc. specific for the connections themselves . These APIs and code paths are not the same used by end users when interacting with things like My sites as they will leverage the content databases within SQL and not making connections directly back to AD . Thus this issue will not impact End user interactions with My sites. "

From Microsoft's assessment, it looks like it is behaving as designed with impact limited to administrative functions.

So essentially, yes, it is horribly horribly slow. But since it only makes the IT people need a drink, there's no need to do anything about it.