Record an analysis and solution to a difficult SharePoint performance problem

A friend's SharePoint 2007 Environment experiences fast and slow opening of the same page.

 

After some troubleshooting, there are the following phenomena:

1. It seems that all pages are slow, but the layouts page seems to have never been slow.

2. This problem only occurs in the range of a single site set. That is, the new site set does not have this problem.

3. the problem occurs in time distribution, which seems to be irregular. After each IISReset, the first opening of blank pages on the problematic site is slower than that on other site sets on the same server.

4. When the problem occurs, the server's CPU and memory are normal.

5. Due to the uncertain time of the problem, dump files cannot be collected.

6. There are no related records in SharePoint ULS Log, Event Application Log, and Event System Log.

 

Analysis:

According to phenomena 1 and 2, the target is placed on the master page. the layouts page references the master page on the file system, while the common page on the site references the master page stored in the database.

Symptom 6: there is no error when the page is opened slowly.

This problem occurs on all pages in symptom 1. It means that the slow page opening has nothing to do with the customized content on the page, and the list page of SharePoint is also slow.

Symptom 4: This is irrelevant to the performance of the server.

 

Is the header of the source code of settings. aspx:

 

Is the header of the site homepage source code:

 

After checking the source code of a friend's master page, we found that there are more than 10 Comments on the masterpage, and more than 10 KB of characters are comments.

Our previous article <SharePoint basics 6-ASP. NET Architecture> introduced that the master page technology is required for SharePoint. MSDN article <ASP. the Run-time Behavior of Master Pages section of NET Master Pages> explains that the master page needs to be compiled when it is requested for the first time.

Note that the comments on the master page are not simply ignored. The comments on these master pages are also parsed and involved in compilation, during compilation, it is interpreted as a comment and thus ignored. however, the interpretation and analysis of comments in this process will waste the Compilation Time of the master page.

The reason for this problem is that it takes too long to compile the master page, so the time returned by the requested page is extended. after the master page is compiled, the second request will not be compiled. it is not clear when the compiled master page will need to be re-compiled. at least IISReset must be re-compiled. each time a recompilation is performed, the problem is reproduced.

 

The solution is clear here. Remove unnecessary comments and solve the problem.