Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I figured I would post this here, since it may be related more to the server configuration than the SharePoint configuration or a combination of both? I'm open for ideas to try, or even feedback on things that maybe have been configured incorrectly as far as performance is concerned.

We have a medium MOSS 2007 install prepped and ready for receiving the WSS 2003 data to upgrade. The environment was originally architected by a previous coworker, and I have since added a few configuration modifications to assist with performance before we finally performed the install. When testing the new site collections & SharePoint install (no actual data yet), things seemed a bit slow. I had assumed that it was because I was accessing it remotely. Apparently the client is still experiencing this and it is unacceptably slow.

  • 1 SQL Server running SQL Server 2008
  • 2x SharePoint WFEs - hosting queries (no index)
  • 1x SharePoint Index - hosting index (no queries)
  • MOSS 2007 installed and patched up through December '09 on WFEs & Index
  • All 4 servers are VMs, should have more than sufficient disk space & RAM (don't recall at the moment), and are running Windows Server 2008 - everything is 64-bit.
  • The WFEs have Windows NLB configured, with a DNS name & IP for the NLB cluster. Single NIC on each server (virtual, since VMWare).
  • The Index server is configured as a WFE (outside of the NLB cluster) so that it can index itself and replicate the indexes to the WFEs that will serve the queries.

Everything is configured & working properly - it just takes a minute or two to load a page on the local LAN. The client is still using their old portal (we haven't started the migration/upgrade just yet) so there's virtually no data or users. We need to either further tune the configuration, or fix anything that may have been configured incorrectly which is causing this slowness?

I've already reviewed & taken into account everything that I could find that was relevant before we even started the install. Does anyone have ideas or pointers? Perhaps there's something that I've missed?

Server loads look fine. Nothing is being maxed out. Network bandwidth is nominal. The VMs are spread out on different hosts (though the Index & SQL servers are on the same host).

We've implemented DB maintenance plans to shrink the transaction logs, etc. We've set SQL/antivirus exclusions. We've also tried running some "warmup" scripts - with no change. Initial page loads take upwards of 1 minute, and eventually things speed up.

share|improve this question
Are any of the servers showing significant load? Is it just the initial page load that slow, or do all pages render slowly? – Dominic D Jun 8 '10 at 17:43
what is your VM hypervisor config? – Jim B Jun 8 '10 at 19:40
I'll take a look at the VM hypervisor config - is there anything in particular that I should be looking for? – elorg Jun 10 '10 at 21:19
up vote 1 down vote accepted

After having several different team members look at various aspects of the configurations, we were not able to find any configuration issues or concerns.

Ultimately the solution appeared to be turning off HTTP compression on the WFEs. We tested this by disabling HTTP 1.1 compression in the user's browser. After SIGNIFICANT improvement, we opted to move forward with disabling it on the servers. Performance has been great since then.

Details found here.

share|improve this answer

Going on a hunch here, but it sounds like a DNS issue to me. Can you rule this out with some nslookup queries from each of the VMs, specifically the NLB cluster?

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.