解决SharePoint 2003的爬网性能问题- 之二

从何处下手

============

一般我更喜欢看实时数据, 但是perfmon的日志的功能是一样的. 在本系列的第一部分, 我们例举了应该抓取的每一个计数器. 我们需要集中注意力在那些计数器的一个子集上. 在下面的讨论中, 我会假设网络, 硬盘等都正常, 出问题的是crawler.

让我们先从那个子集开始, 然后到这些计数器都是基于什么的, 并且它们都告诉了我们什么.

 

这些计数器在传达什么信息?

============

在Search Gather object中有很多关键的计数器, 我每次都会查看它们.

  • Search Gatherer\Document Entries
    • 这个计数器代表着当前在队列中等待被爬网的item的数目, item的类型包括文档, 列表, 事件等等.
    • 当这个计数器大于0时,守护进程就识别出有任务需要由crawler来处理, 并启动爬网动作.
  • Search Gatherer\Delayed Documents
    • 这个计数器代表着Search Gather\Document Entries中超过Site Hit Frequency rule的限制, 并且正在等待被爬网的数目. 这种是爬网的正常功能.
    • 这是一种非正式的计数器, 在开始的时候,我并不想针对这个计数器采取什么行动, 但是了解一下数字还是有好处的. 后面的文章里, 我们会更加深入的讨论这个计数器, 讨论它代表的意义.
  • Search Gatherer\Documents Filtered\Documents Filtered Rate
        • 这两个计数器是一起工作的. Documents filtered计数器代表着被deamon filtered过的文档的个数. 这并不代表着成功的爬网, 它仅仅指示出被标识为completed的文档的个数.
        • 当一个文档被爬的时候, 典型地它会被传送给某种IFilter. 并不是所有的item都有IFilter, 如果没有的话它们也会被类似于IFilter的东西处理. 比如说, 当你从Active Directory中导入用户的时候, 并没有什么people IFileter存在, 所以另外一部分的代码会处理这种特别的item. 底线是党一个item被完全爬过的时候, 这个计数器就会增长.
        • Documents Filtered Rate是每秒钟的Documents Filtered的值. 这个数值在估量爬网时间长短时比较有用. 比如说, 可以根据下面的公式来对爬网的时间进行估计:
          • 剩下的时间(秒)=Search Gatherer:Document Entries 除以Search Gatherer:Documents Filtered Rate
          • 剩下的时间(分钟)=Estimated Seconds Remaining 除以 60
        • 使用这个估计的技巧, 我们可以对剩余的时间有个大致的感觉. 比如说使用上面的公式, 你可以得到下面的计算
          • 3249 (Document Entries) / 4 (Documents Filtered Rate) = 812.25 (est. seconds remaining)
          • 812.25 (est. seconds remaining) / 60 (seconds in a minute) = 13.53 (est. minutes remaining)
      • 我得再次强调, 这只是一种估计. 因为实际上crawler可以filter的文档的数目每一秒都在变化, 而且变化的幅度还经常会很大. 我见过某些客户的环境中, 从每秒140到150个文档每秒的处理速度一下子下降到每秒2个. 另一个原因是, 当crawler遇到了一个拥有很多链接的文档, 这会引起Search Gatherer\Document Entries数值的增长. 所以这只是一种猜测和估计, 估计大致会花费多少时间. 
  • Search Gatherer\Documents Successfully Filtered and \Documents Successfully Filtered Rate
    • 这两个计数器是一起工作的. 计数器Documents Successfully filtered代表着被某守护进程filter过的, 并且是没有错误从IFilter中返回的文档的数目.
    • 底线是, 当一个item被完全爬过并没有错误发生的时候, 这个Documents Successfully Filtered 计数器会增加.
    • Search Gatherer\Documents Successfully Filtered Rate 是每秒钟的Documents Successfully Filtered的值
  • Search Gatherer\Heartbeats
    • 这个计数器是搜索过程的基本的心跳指示器. 它每十秒钟增加一下. 通常情况下我使用这个计数器来确定搜索已经运行了多久, 因为该计数器都是从上次搜索启动开始时进行累加的.

在后面的文章中, 我会讨论更多的计数器以及他们的意义.

 

资料来源:

SharePoint Portal Server 2003 Crawl Performance Part 2

http://blogs.msdn.com/b/tonymcin/archive/2006/11/10/sharepoint-portal-server-2003-crawl-performance-part-2.aspx

posted on   中道学友  阅读(326)  评论(0编辑  收藏  举报

编辑推荐:
· AI与.NET技术实操系列:向量存储与相似性搜索在 .NET 中的实现
· 基于Microsoft.Extensions.AI核心库实现RAG应用
· Linux系列:如何用heaptrack跟踪.NET程序的非托管内存泄露
· 开发者必知的日志记录最佳实践
· SQL Server 2025 AI相关能力初探
阅读排行:
· 震惊!C++程序真的从main开始吗?99%的程序员都答错了
· 【硬核科普】Trae如何「偷看」你的代码?零基础破解AI编程运行原理
· 单元测试从入门到精通
· 上周热点回顾(3.3-3.9)
· winform 绘制太阳,地球,月球 运作规律
历史上的今天:
2009-11-04 汇编语言基础之八- 动手练习,将前面的知识用于实践
2009-11-04 汇编语言基础之七- 框架指针的省略(FPO)

导航

< 2010年11月 >
31 1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 1 2 3 4
5 6 7 8 9 10 11

技术追求准确,态度积极向上

点击右上角即可分享
微信分享提示