nutch1.2 fetcher类解析

建索引这段，一直在fetcher这里消耗的时间最多，webhavest抓数据nutch解析数据建索引500条不重复数据大概需要40-50分钟，光fetch就耗了30分钟左右，所以提高建索引速度，fetch优化是必须的，在优化前，先得知己知彼

fetcher的类结构

内部类

inputFromat 没研究是干什么的

Fetchitem

FetchItemQueues

QueueFeeder

FetcherThread         //多线程解析crawldb中的数据

FetchItemQueue

主要的方法

run(String[])   //本类中的mian方法调用的就是它  该方法调用的是fetch(segment, threads, parsing)   

                         segment=crawldb的位置  threads=读取

                                     配置文件中的fetcher.threads.fetch的值   parsing=?

fetch(segment, threads, parsing)    //在这调用mapreduce结构算法   逻辑方法调用的是本类中的

                                                                 run(RecordReader<Text, CrawlDatum> input,

                                                                             OutputCollector<Text, NutchWritable> output, Reporter reporter)

run(RecordReader<Text, CrawlDatum> input,

                   OutputCollector<Text, NutchWritable> output, Reporter reporter)

                                  // 首先new QueueFeeder() 然后调用run方法  

                                             这个类中消耗的时间并不多，所以没有深入

                                  //  然后根据配置文件的fetcher.threads.fetch的值

                                               创建多个FetcherThread对象  然后调用其run()

FetcherThread类的run()    //这里是重点消耗时间的地方了。

run()方法大概结构                             

while(true){

    FetchItem fit = fetchQueues.getFetchItem();      //这里在fit==null有个判断  是跳出本次循环还是跳出所有循环

do{

Protocol protocol = this.protocolFactory.getProtocol(fit.url.toString());

//通过传入的crawldb中的url  通过接口调用nutch的插件来下载不同格式的数据

ProtocolOutput output = protocol.getProtocolOutput(fit.url, fit.datum);

//然后根据不同格式的数据 调用相应插件来解析

//在ProtocolOutput对象中会有个URL返回值 如200,400,500    通过这些值判定进入哪个case分支

//因为我的数据中，已经通过webharvest脚本抓取并过滤掉了无用数据，所以在前面通过url下载数据解析数据那部分被我去掉了，用自己构造的//ProtocolOutput代替了  所以在case这部分只会进入200也就是ProtocolStatus.SUCCESS分支

}while()

}

以本次抓取的453条不重复数据为基础   整个run方法耗时 10:07:17  到   10:44:48    总共10个FetcherThread对象执行
线程1    fit==null 的次数=4502   跳出所有循环2次
         最外面的while(true)执行次数4605
         里面的do while执行次数103


2        
         4504        2
         4507
         3


3
         4504        2
         4525
         21

4        
         4503        2
         4532     
         29

5
         4503        2
         4514
         11

6
         4502        2
         4658
         155

7
         4503
         4515
         12

8
         4503
         4541
         38

9
         4503
         4547
         44
10
         4503
         4539
         36


傻人傻办法，，
do while是以传入的crawldb数据量来计算的，
每个线程耗的时间是以运行时最长的那个计算，
上面的数据明显看出10个线程数据分配有问题，有的线程给的数据很多，有的很少，间接拉长线程执行时间，但是为什么会造成这个结果，还不清楚。
如何优化，还有待研究