记一个较困难的SharePoint性能问题的分析和解决

一个朋友的SharePoint 2007环境, 存在相同页面打开时快时慢的现象.

 

经过一番排查, 有如下的现象:

1. 似乎所有页面都存在时快时慢的问题, 但layouts页面似乎从未有过打开慢的情况发生.

2. 该问题仅发生在单个site集的范围. 即, 创建的新站点集中不存在这样的问题.

3. 问题发生在时间分布上看似乎并无规律, 感觉每次IISReset之后, 问题站点上空白页面的首次打开要比相同服务器上的其他站点集上的空白页面要慢.

4. 问题发生时, 服务器的CPU和内存都正常.

5. 由于问题发生的时间不确定, dump文件无法收取.

6. SharePoint ULS Log, Event Application Log, Event System Log中均无相关记录.

 

分析:

根据现象1, 2, 把目标放在了master page上. 因为, layouts页面引用的是文件系统上的master page, 而站点上的普通页面引用的是存放于数据库中的master page.

现象6, 说明页面打开缓慢的过程中并不存在错误.

现象1中的所有页面都存在这样的问题说明页面打开慢跟页面上的订制的内容无关, SharePoint的列表页面也慢的嘛.

现象4说明这与服务器本身的性能状态无关.

 

下图是settings.aspx的源代码的头部分:

 

下图是站点首页源代码的头部分:

 

检查了朋友的master page源代码, 发现该masterpage上有超多的注释, 10K以上的字符是注释.

我们之前的文章<<SharePoint基础之六- SharePoint基础架构中涉及的ASP.NET架构>>介绍了SharePoint是需要使用master page技术的. MSDN上的文章<<ASP.NET Master Pages>>的Run-time Behavior of Master Pages的部分解释了master page在首次被请求的时候, 是需要编译的.

这里需要注意的是, master page中的注释并不会被简单地忽略掉, 这些master page中的注释也会被解析, 并参与到编译当中, 编译时才会被解释为注释从而忽略. 然而, 这个过程中对于注释的解释和分析是会浪费master page的编译时间的.

这个问题的原因就是因为master page编译需要的时间太久了, 所以拉长了被请求页面返回的时间. master page被编译之后, 第二次请求就不会再编译了. 什么时候这个已编译的master page会需要重新编译我并不清楚. 至少IISReset肯定是会需要重新编译的. 每重新编译一次, 问题就会重现一次.

 

到这里解决方案就很清晰了. 移除多余的注释, 问题解决.