We came across a challenge with one of our clients where they were seeing a SharePoint project site take up to one and a half minutes to load each morning. After the initial load, the site was far more responsive but the problem could return once or twice that same morning.

We started off by looking at all the normal things like if the site was jam-packed with web parts that were causing the server issues. We also looked at the server resources and they all looked fine and had plenty of resources. We also noticed that just loading the SharePoint settings pages took far too long. Furthermore, when you reloaded the pages they would come up almost instantly.

For these reasons I knew straight away, we were looking at a generic SharePoint issue. My first port of call was to look at IIS more closely.

Analysis

I took a meeting with the client one morning and first cleared their cache, and then pinged their site domain. The machine was pointing to PM02 10.10.10.202 via a round-robin session. We reproduced the issue straight away by connecting to the site.

So now I wanted to point the client through each web front end and see if the issue existed on each one. So changed their host file to point at PM04 10.10.10.204 WFE but we did not reproduce the issue (I thought maybe their DNS had pointed the client machine at this WFE on an earlier session).

We changed the host file again to PM01 10.10.10.201 and we reproduced the issue. Then at PM03 10.10.10.203 and again we reproduced the slow load issue. I then was able to cycle between each machine(twice or more per machine) while updating the host file and we could no longer reproduce the issue.

Conclusion

The above testing and reproductions helped me conclude that once the client machine had loaded the site once from each web front end server, it could then load the site without issue from that server. It appeared that the server itself and the client were loading a large amount of session data. With four web front end servers in the farm being distributed via DNS round robin load balancing, this potentially meant one user could see this issue four times in a day. Granted users would probably need to be clearing their cache or using different browsers but it does illustrate how the issue could be quite damaging to their productiveness.

I concluded that app pools normal procedure for recycled once nightly was the issue we were seeing.

Recommendations

In this case, a warm-up script resolves the issue being experienced by the users. E.g. their first requests to the server will not take as long as the server will have recompiled its tables before the first request.

Image credit