heritrix 提高抓取速度

本文分享了Heritrix爬虫速度慢的问题及解决方法,通过调整配置将爬取时间从8小时缩短到2小时。

最近一直用heritrix爬取网站,  晚上heritrix一直运行着, 但奇怪的是heritrix 抓取速度非常慢, 抓取一个网站, 用了8个多小时, 竟然没有运行完。 于是根据LOG 分析了一下慢的原因

 

 -----===== SNOOZED QUEUES =====-----
SNOOZED#0:
Queue us,imageshack,img245,+2 (p1)
  1 items
   wakes in: 99m19s74ms
    last enqueued: http://img245.xxx.us/img245/596/193183637x01ss500sclzzzbx0.jpg
      last peeked: http://img245.xxxx.us/img245/596/193183637x01ss500sclzzzbx0.jpg
   total expended: 12 (total budget: -1)
   active balance: 2988
   last(avg) cost: 1(1)
   totalScheduled fetchSuccesses fetchFailures fetchDisregards fetchResponses robotsDenials successBytes totalBytes fetchNonResponses
   2 1 0 0 1 0 59 59 12
   SimplePrecedenceProvider
   1

 SNOOZED QUene 里面有一些图片一直在那里, 并且运行时间相当长,

用浏览器打开, 那图片不存在,于是那图片一直在QUENE当中。

 

接着我分析了一下heritrix 中代码:

 

workQueneFrontier 有下面代码, 由于图片不存在会进入needsRetrying代码块中。

      
        if (needsRetrying(curi)) {
            // Consider errors which can be retried, leaving uri atop queue
            if(curi.getFetchStatus()!=S_DEFERRED) {
                wq.expend(curi.getHolderCost()); // all retries but DEFERRED cost
            }
            long delay_sec = retryDelayFor(curi);
            curi.processingCleanup(); // lose state that shouldn't burden retry

                wq.unpeek(curi);
                // TODO: consider if this should happen automatically inside unpeek()
                wq.update(this, curi); // rewrite any changes
                if (delay_sec > 0) {
                    long delay_ms = delay_sec * 1000;
                    snoozeQueue(wq, now, delay_ms);
                } else {
                    reenqueueQueue(wq);
                }

            // Let everyone interested know that it will be retried.
            appCtx.publishEvent(
                new CrawlURIDispositionEvent(this,curi,DEFERRED_FOR_RETRY));
            doJournalRescheduled(curi);
            return;
        }

 

 

 

 retryDelayFor方法是用来抓取失败, 计算等待的时间, 代码于如下

 

    /**
     * Return a suitable value to wait before retrying the given URI.
     * 
     * @param curi
     *            CrawlURI to be retried
     * @return millisecond delay before retry
     */
    protected long retryDelayFor(CrawlURI curi) {
        int status = curi.getFetchStatus();
        return (status == S_CONNECT_FAILED || status == S_CONNECT_LOST ||
                status == S_DOMAIN_UNRESOLVABLE)? getRetryDelaySeconds() : 0;
                // no delay for most
    }

    public int getRetryDelaySeconds() {
        return (Integer) kp.get("retryDelaySeconds");
    }

 

由于heritrix 默认是等待900秒, 也就是15分钟, 如果抓取失败一个小时也只能运行4次, 8 个小时也就是32次, 难怪一直在运行啊

 

  /** for retryable problems, seconds to wait before a retry */
    {
        setRetryDelaySeconds(900);
    }

 知道原因后就好办了, 修改一下配置文件:

 

 <!-- FRONTIER: Record of all URIs discovered and queued-for-collection -->
 <bean id="frontier" 
   class="org.archive.crawler.frontier.BdbFrontier">
  <!-- <property name="holdQueues" value="true" /> -->
  <!-- <property name="queueTotalBudget" value="-1" /> -->
  <!-- <property name="balanceReplenishAmount" value="3000" /> -->
  <!-- <property name="errorPenaltyAmount" value="100" /> -->
  <!-- <property name="precedenceFloor" value="255" /> -->
  <!-- <property name="queuePrecedencePolicy">
        <bean class="org.archive.crawler.frontier.precedence.BaseQueuePrecedencePolicy" />
       </property> -->
  <!-- <property name="snoozeLongMs" value="300000" /> -->
   <property name="retryDelaySeconds" value="90" /> 
  <!-- <property name="maxRetries" value="30" /> -->
  <!-- <property name="recoveryDir" value="logs" /> -->
  <!-- <property name="recoveryLogEnabled" value="true" /> -->
  <!-- <property name="maxOutlinks" value="6000" /> -->
  <!-- <property name="outboundQueueCapacity" value="50" /> -->
  <!-- <property name="inboundQueueMultiple" value="3" /> -->
  <!-- <property name="dumpPendingAtClose" value="false" /> -->
 </bean>

 

这是heritrix3的配置, 把时间改成90秒, 也就是只等待1分半钟,

如果是H1的配置, 那可以用管理界面进行配置。

改了一下速度一下提高了很多, 原来8小时才能爬完一个网站, 现在2个小时就行了。

如果再用一下heritrix

增量抓取, 那下次再抓取这个网站时, 速度又会增加很多。这样问题解决了

 

 

AI 代码审查Review工具 是一个旨在自动化代码审查流程的工具。它通过集成版本控制系统(如 GitHub 和 GitLab)的 Webhook,利用大型语言模型(LLM)对代码变更进行分析,并将审查意见反馈到相应的 Pull Request 或 Merge Request 中。此外,它还支持将审查结果通知到企业微信等通讯工具。 一个基于 LLM 的自动化代码审查助手。通过 GitHub/GitLab Webhook 监听 PR/MR 变更,调用 AI 分析代码,并将审查意见自动评论到 PR/MR,同时支持多种通知渠道。 主要功能 多平台支持: 集成 GitHub 和 GitLab Webhook,监听 Pull Request / Merge Request 事件。 智能审查模式: 详细审查 (/github_webhook, /gitlab_webhook): AI 对每个变更文件进行分析,旨在找出具体问题。审查意见会以结构化的形式(例如,定位到特定代码行、问题分类、严重程度、分析和建议)逐条评论到 PR/MR。AI 模型会输出 JSON 格式的分析结果,系统再将其转换为多条独立的评论。 通用审查 (/github_webhook_general, /gitlab_webhook_general): AI 对每个变更文件进行整体性分析,并为每个文件生成一个 Markdown 格式的总结性评论。 自动化流程: 自动将 AI 审查意见(详细模式下为多条,通用模式下为每个文件一条)发布到 PR/MR。 在所有文件审查完毕后,自动在 PR/MR 中发布一条总结性评论。 即便 AI 未发现任何值得报告的问题,也会发布相应的友好提示和总结评论。 异步处理审查任务,快速响应 Webhook。 通过 Redis 防止对同一 Commit 的重复审查。 灵活配置: 通过环境变量设置基
【直流微电网】径向直流微电网的状态空间建模与线性化:一种耦合DC-DC变换器状态空间平均模型的方法 (Matlab代码实现)内容概要:本文介绍了径向直流微电网的状态空间建模与线性化方法,重点提出了一种基于耦合DC-DC变换器的状态空间平均模型的建模策略。该方法通过数学建模手段对直流微电网系统进行精确的状态空间描述,并对其进行线性化处理,以便于系统稳定性分析与控制器设计。文中结合Matlab代码实现,展示了建模与仿真过程,有助于研究人员理解和复现相关技术,推动直流微电网系统的动态性能研究与工程应用。; 适合人群:具备电力电子、电力系统或自动化等相关背景,熟悉Matlab/Simulink仿真工具,从事新能源、微电网或智能电网研究的研究生、科研人员及工程技术人员。; 使用场景及目标:①掌握直流微电网的动态建模方法;②学习DC-DC变换器在耦合条件下的状态空间平均建模技巧;③实现系统的线性化分析并支持后续控制器设计(如电压稳定控制、功率分配等);④为科研论文撰写、项目仿真验证提供技术支持与代码参考。; 阅读建议:建议读者结合Matlab代码逐步实践建模流程,重点关注状态变量选取、平均化处理和线性化推导过程,同时可扩展应用于更复杂的直流微电网拓扑结构中,提升系统分析与设计能力。
内容概要:本文介绍了基于物PINN驱动的三维声波波动方程求解(Matlab代码实现)理信息神经网络(PINN)求解三维声波波动方程的Matlab代码实现方法,展示了如何利用PINN技术在无需大量标注数据的情况下,结合物理定律约束进行偏微分方程的数值求解。该方法将神经网络与物理方程深度融合,适用于复杂波动问题的建模与仿真,并提供了完整的Matlab实现方案,便于科研人员理解和复现。此外,文档还列举了多个相关科研方向和技术服务内容,涵盖智能优化算法、机器学习、信号处理、电力系统等多个领域,突出其在科研仿真中的广泛应用价值。; 适合人群:具备一定数学建模基础和Matlab编程能力的研究生、科研人员及工程技术人员,尤其适合从事计算物理、声学仿真、偏微分方程数值解等相关领域的研究人员; 使用场景及目标:①学习并掌握PINN在求解三维声波波动方程中的应用原理与实现方式;②拓展至其他物理系统的建模与仿真,如电磁场、热传导、流体力学等问题;③为科研项目提供可复用的代码框架和技术支持参考; 阅读建议:建议读者结合文中提供的网盘资源下载完整代码,按照目录顺序逐步学习,重点关注PINN网络结构设计、损失函数构建及物理边界条件的嵌入方法,同时可借鉴其他案例提升综合仿真能力。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值