枪打出头鸟

昨天做测试不小心弄错了,在那个时间段访问的朋友会收到抓取频繁的通知,不用担心。

为什么要测试呢,看上图。

昨天总共用去33G,是近几天最少的。我用的是最便宜的主机,每月1000G,简单乘一下就知道,一定是超了。

暂时的忍耐度是2%,超过的会收到抓取频繁的信息提示修改设置。受影响的非常少。

说过太多次了,我去抓别人网站最多也就是半小时一次,你分分钟都来更新,只是更新了个寂寞。(此话基本针对有自己服务器的,这前几位已经占去10%以上的流量,可供参考的feedly只用了60m左右)

不想升级,没钱。

5条评论

  1. 如果自己看,每日一次都不一定看得完。
    这种属于高频次的,更接近商业用途,应该请他们自己承担商业带宽的成本。

  2. 请问是否可以加上RSS 的 TTL 字段呢。可以按照抓间隔给ttl。对于正确实现的RSS reder 可以减少ttl内的请求次数节省带宽

    1. 我觉得不会起太大作用,这算个君子协定吧。因为那些流量比较大的服务器程序一般都会有获取时间间隔选项(通常默认时间还都挺短),我觉得他们根本不会去参考ttl的,我管你的推荐设置呢。
      感谢,试试也无妨。
      我觉得正常健康的抓取不应该比feedly、inoreader超出太多,这也是以后封禁的一个参考。

      找到一个比较详细的
      https://www.rssboard.org/rss-profile#element-channel-ttl

      1. 一般大型的程序会专门有一个bot去抓取。特别是feedly, inoreader这种。bot大多会使用Range Header 抓前面的lastBuildTime和ttl。然后通知feed更新。

        1. 不是分析lastbuiledtime或ttl,应该是判断Last-Modified和If-Modified-Since。
          看日志就能看出feedly inoreader tts outlook等都很规矩,GET请求会带条件,没更新的话服务器返回304,数据量为0。但绝大部分程序都是直接GET请求,并不判断If-Modified-Since,服务器返回200。
          上面我找的链接说当时连google reader 都不支持ttl。

Z进行回复 取消回复

您的电子邮箱地址不会被公开。 必填项已用*标注