解决SharePoint 2003的爬网性能问题- 之八
IFilters
==============
爬网时, IFilter为守护进程承担了很多的重活儿. IFilter的标准里说明了如何写一个IFilter. 当一个IFilter被写好并部署之后, 他就可以被各种不同的爬网引擎使用了, 这些爬网引擎里就包括SharePoint.
在这篇文章里我们会讨论如何确定一个IFilter是被标记为供一个单线程的守护进程使用还是被一个多线程的守护进程使用.
首先我们要理解为什么单线程跟多线程要进行对比, 这很重要. 这些最终都归于某一时刻, 某种类型的文档究竟能有多少文档可以被爬网. 当gatherer首先启动守护进程来爬文档的时候, 它会启动一个被叫做multi-threaded deamon(守护进程)(MT). 这种类型的守护进程可以同时爬32个文档. 这意味着很多文档可以在较少的一段时间内被同时处理. 另一种类型的守护进程叫做single-threaded deamon(ST). 这种类型的守护进程一次只能爬一个文档.
在处理文件的时候, 扩展名会决定应该使用的IFilter. IFilter的注册(registration)会让守护进程确定选择并使用哪一个iFilter. 如果一个IFilter是线程安全(thread safe)的, 并且可以与MT的守护进程协同工作, 并且它的注册也是正确的话, 它就会被MT守护进程加载起来. 否则, 它就会被ST的deamon加载.
如何确定一个IFilter的线程模型(How to determine the threading model of an IFilter )
================
当一个IFilter被注册到系统中, 线程模型就已经被指定了, 之后会公布给所有的客户这个IFilter是否是线程安全的. 你可以指定你自己的注册表键值来确定某种文件类型使用什么IFilter, 并且确定这种IFilter是否是线程安全的.
- 启动Indexer机器, 打开注册表编辑器. 你需要选择HKEY_CLASSES_ROOT来开始. 因为我们想要研究.DOC文件, 所以我们需要打开HKCR\.doc\PersistentHandler路径. 这个路径里有一个类型为REG_SZ的default键值. 这里列出的是一个GUID. 为了在这里方便讨论, 我会简单地用GUID1来引用它. 你需要记录下这个GUID来继续下面的步骤.
- 接下来, 你需要导航到HKCR\CLSID\{guid1}路径. 一旦到这个地方, 你就会发现一个节点在这个level的下面, 叫做PersistentAddinsRegistered. 在这个level下面, 你会看到另外一个节点也是GUID. 我们称之为GUID2.
- 点击GUID2. 这个路径展现了一个类型为REG_SZ的default键值. 这个列出的键值是另外一个GUID. 我们称它为GUID3。 你需要记录下这个GUID来进行下面的步骤.
- 有了GUID3, 你会需要导航到路径HKCR\CLSID\{guid3}\InprocServer32下. 这里你可以看到下面的信息:
- (default) 这是一个包含IFilter实现的DLL.
- ThreadingModel 这是对线程安全的指定
- Both - 指示出这个DLL既可以被ST守护进程使用, 也可以被MT守护进程使用.
- Apartment - 指示出这个DLL只能被ST守护进程使用.
- Free - 指示出这个DLL既可以被ST守护进程使用, 也可以被MT守护进程使用.
.DOC后缀名的例子(Example using the .DOC extension)
==================
作为这个例子, 我会拿Microsoft Word 文件类型(.doc), 但是这里的方法适用于所有的文件类型.
- 打开 HKCR\.doc\PersistentHandler 发现(default) key 的值是{98DE59A0-D175-11CD-A7BD-00006B827D94}. This is GUID1.
- 打开 HKCR\CLSID\{98DE59A0-D175-11CD-A7BD-00006B827D94}. 看到 PersistentAddinsRegistered 还有在它下面的GUID. 下面的这个GUID是{89BCB740-6119-101A-BCB7-00DD010655AF} , 即GUID2.
- 打开 HKCR\CLSID\{98DE59A0-D175-11CD-A7BD-00006B827D94}\PersistentAddinsRegistered\{89BCB740-6119-101A-BCB7-00DD010655AF} 发现(default) key 的值是{F07F3920-7B8C-11CF-9BE8-00AA004B9986}. 这是GUID3.
- 打开HKCR\CLSID\{F07F3920-7B8C-11CF-9BE8-00AA004B9986}\InprocServer32 发现这个路径下有两个条目. 发现 offfilt.dll 时包含IFilter实现的DLL文件, 还发现它的ThreadingModel是Both.
Real life
==================
你会发现有些IFilter的DLL被标识为Both, 但实际上它被标识为了Apartment. 这个不正确的结果是不可预知的. 在SharePoint中, 你也许会发现MT的守护进程进程在Application Event Log中记录ID为1000的事件, 意味着它经常的crash. 这是IFilter线程安全问题的一个第一个表象.
你应该联系你的IFilter的供应商来确定他们的IFilter是否是线程安全的. 你应该确定这一点, 这样才可以跟MT的守护进程协同工作. IFilter本身就可以帮助你提高整个爬网的性能. 但是如果一个IFilter被错误地标识了, 它会因为崩溃而引发很多性能问题.
(本系列完结)
资料来源:
SharePoint Portal Server 2003 Crawl Performance Part 8
