Site Hit Frequency Rules
=====================
Site Hit Frequency rule (SHF)是解决性能问题的强大工具. 正如我学到的, 许多人并不真正的理解它, 也不知道如何使用它来帮助我们解决性能调优问题.
在调优性能问题的时候, 理解 "不是所有的时候都要追求速度" 这一点非常重要. 我们都想要爬网能不到一个小时结束, 但是根据你的内容的大小, 这并不是总能够达到的目标.
SHF规则可以帮助我们提高那些不怎么强大的服务器的性能. 比如说, 我们内部爬网的目标是一台物理上并不强大的位于德国的服务器. 它是一台在某人桌子底下的web server, 可能拥有一个500-600MHz的处理器. 就这台机器的本职工作来说, 可能它还干的不错, 但是可能它就受不了gatherer爬它的时候对它带来的影响. 所以SHF就被创建出来, 用来减轻对这台机器的影响.
Request Frequency在屏幕上有三种选择, 每项选择都有它自己的用处. 这三个选项是:
- 并发请求文档数(Request documents simultaneously )
- 并发请求文档数上限(Limit the number of documents requested simultaneously)
- 每次请求后等待的时间(Wait a specified amount of time after each request)
我们会用反序讨论这些选择. 选项Wait a specified amount of time after each request 所做的跟字面意思一样. 如果你放30秒在这个选项中, 那么gatherer会在成功访问一个文档后灯30秒, 之后再请求下一个文档. 这就是我们为这台位于德国的服务器指定的SHF. 它工作的很好, 因为这台机器上的所有内容最终都会被完全爬过, 并且机器的性能也没有收到很大影响.
选项Limit the number of documents requested simultaneously 也跟字面意思一样. 如果设置文档数量为3的话, 那么gatherer会同时请求三个文档, 不会再多了. 它限制了针对某台服务器的并发连接数. 当我们谈到第三个选项也就是最后的选项的时候, 理解这个概念是很重要的. 你可以使用这个门槛来限制发往一台服务器的连接数, 或者移出这种限制, 来让gatherer尽可能的又多又快地从这台服务器获取数据. 这里是你很快就会发现的强大之处.
选项Request documents simultaneously 是默认的, 并且它带来的强度可以压倒某些服务器, 所以请有节制地使用这个选项. 这个选项会一次尽可能多地从目标服务器获取文档. 使用这个选项可以迅速地提升同往服务器的连接数, 当然同时这还取决于可用的filtering threads的数量.
如果你读过本系列的第四部分, 你就会记得我们讨论过Search Gatherer\Server Objects. Server object相当于一个行政长官. 当一个server object被创建出来之后, 它就会给自己设置一个默认的连接到本机的连接的最大值. 在indexer上该值的计算公式是maxConnection = 4 + number of procs on indexer. 所以, 我的例子中, 我有一个双proc的服务器, 所以如果我爬自己的机器的话, 那么连接数就是4+2=6. server object会限制你的indexer上的并发连接数在任意时刻最大不超过6. 这样做是有合理的理由的. crawler想做一个好市民, 爬网时不想拖垮目标服务器. 这样的默认值就比较合理, 即能比较快的拿到数据又不会拖垮目标服务器.
如果你多想想的话, 会发现在perfmon的计数器里这样的设计会引发许多有趣的行为. 比如说, 如果我只爬我自己的一台服务器, 并且我有32个filtering threads. 假设我所有的内容都包含在那台机器自身里, 那我就能看到仅有6个线程时工作的, 其他的都处于空闲状态. 在所有的性能调优中, 总会有一个瓶颈, 在这种情况下的瓶颈就是server object了.
SHF规则可以被用来覆盖掉这个最大连接数的限制. 这是整个性能调优里的比较关键的地方. 如果你的indexer已经处于CPU使用率的巅峰状态, 或者是磁盘的巅峰状态的话, 那么使用Request documents simultaneously option 就会对你带来消极影响. 原因是如果你配置了这个选项, 它会增加你的indexer服务器的负载. 这可能并不是你想要做的. 我建议多试验几次, 同时记录下你的操作来理解怎样做对你的环境是最好的.
我的测试方法是使用Limit the number of documents requested simultaneously 选项. 我选择在那个SHF规则里填'10'. 然后进行测试. 我注意到我的机器可以处理的很好. 于是我逐渐地进行调整, 加到了32也没遇到什么问题. 所以, 当我到达某个数值觉得还OK的时候, 我就把这个值设置到Request documents simultaneously 选项中. 在爬SharePoint站点的时候, 如果机器够强大, 那么这么做是没什么问题的.
如果对一台文件服务器设置了Request documents simultaneously 选项, 你会注意到这项改变对文件服务器和索引服务器的影响会非常明显. 再次强调, 你必须在你的环境中进行调整. 我曾经跟一个客户一起工作, 该客户的环境非常庞大, 完全可以处理高负荷, 但是他们被默认的server object所允许的最大值所限制. 他们刚刚把几个SharePoint服务器场都整合到了一个服务器场中. 这意味着server object所暴露的连接限制对于他们的环境来说太严格了. 我们添加了一个SHF规则, 发现gatherer开始让空闲的线程也开始工作了. 我们还发现gatherer在爬文档的时候速度也有加快. 这台机并没有受到什么影响, 但是我们在自己的环境中调优的时候要确保我们做的修改是不是在我们的环境下也可以达到同样的效果.
当gatherer爬SharePoint站点的时候, 它在使用前端服务器上的web service, 所以你需要监控那台前端来确保这些额外的数据传输不会超出那台服务器的处理能力. 还有, 这种调优同时也增加了压给SQL服务器的工作量, SQL服务器也要监控一下.
如果使用恰当的话, SFH规则可以极大地提升爬网性能, 但同时它也可能成为你敌人, 所以在使用这项规则的时候要小心地注意对其他机器带来的影响.
后续的文章, 我们继续讨论性能调优的要点.
资料来源:
SharePoint Portal Server 2003 Crawl Performance Part 7