At the moment I am troubleshooting a very slow (response times of 10+ seconds monitored with Fiddler) responding SharePoint 2007 intranet at a customer. At first we thought that the problems where caused by network traffic from SharePoint to SQL because this was routed through the load balancer (Windows 2008 NLB). We configured the route tables on the SharePoint servers but this only caused a slight improvement in performance.
We also saw that object and output cache were both not configured on the site collections. So we also configured both the cache options. Object cache with a size of 200MB per site collection and a refresh time of 600 seconds. Output cache was switched on with the verified cache profile option set to Intranet. Almost immediately after these configurations were done, the helpdesk received lots of phone calls by users. The users reported that it seemed that they were logged on as an other user. After switching off output cache this was solved.
This Technet article also describes the limitations of NLB combined with output caching:
When used with two or more Web servers, output caching might affect consistency. You can configure a cache profile not to check for updates for each request and, for example, configure the profile to ignore changes to the version of the Web page in the output cache until 60 seconds after the original page is updated. If you have two Web servers in your topology, and depending on the load balancer used to route the user’s request, a reader might see inconsistent content if the page is rendered by one server and then a later request is routed to a second server within that 60-second window.
Tags: Infrastructure, performance
No comments:
Post a Comment