很多站长把注意力放在“蜘蛛来没来”，却很少关心“蜘蛛一次来多少”。实际上，同一时间发起的请求数量（并发）和单位时间内的请求总量（速率），直接决定了蜘蛛能在你的站点上走多深。理解这两件事，才能明白为什么有些站点抓取顺畅，有些站点总是被轻轻点一下就走了。
蜘蛛的并发不是无限的
抓取程序通常会对同一个域名维持一个连接池，同时保持若干条连接。这个数字没有公开的固定值，它和站点整体健康状况、历史响应速度，以及抓取程序当时的资源调度都有关系。表现到日志上，就是同一个时间段里，来自蜘蛛的请求是交织出现的，而不是一条接一条。
由此可以得出两个结论：
- 页面响应越慢，同样的连接数能完成的抓取量越少；
- 站点一旦出现大量超时，蜘蛛会主动收窄并发，而恢复起来比降下来慢得多。
限速信号从哪里来
站点能施加的限速手段大致有三类，优先级和效果并不相同：
- 服务端返回 429 或 503。这是最直接的反馈。429 表示请求过多，503 表示服务暂时不可用。两者都会让抓取节奏明显放缓，区别在于 503 通常会被理解为站点整体故障，影响面更大。
- robots.txt 里的 Crawl-delay。它对部分蜘蛛有效，但并非所有抓取程序都会严格执行，把它当作唯一手段并不稳妥。
- 控制台里的抓取速度设置。多数搜索引擎提供了限速选项，作用范围是本站，适合在压测或大促期间临时下调。
容量准备：先算清楚能扛多少
与其被动限速，不如先算一笔账。假设日志里观察到蜘蛛峰值是每秒若干次请求，而这个峰值恰好出现在你最慢的一批动态页面上，那么真实的资源消耗要按最慢那类页面来估。一个粗略但实用的做法是：
- 挑出抓取量占比最高的 10 个 URL 模板；
- 测出它们各自的平均响应时间；
- 用峰值请求数乘以平均响应时间，估算需要的并发处理能力。
如果算出来的数字已经接近服务器上限，那就不该等蜘蛛自己撞墙，而应提前对慢页面做缓存或静态化。
响应时间的波动比平均值更值得关注
平均值好看不代表稳定。日志里如果出现“大部分请求 50 毫秒，少数请求 8 秒”这样的分布，说明存在慢查询或锁竞争。这类毛刺对抓取节奏的伤害，往往比整体偏慢更大——蜘蛛遇到几次超时，就可能降低整站的抓取频率。
什么时候该主动降速
以下几种情况，主动降低抓取速度是合理选择：
- 站点正在做数据库迁移、索引重建等重运维操作；
- 新上线的功能还没经过压测，响应时间不可预期；
- 日志显示磁盘 IO 或数据库连接数已经接近上限。
降速期间不要顺手把 robots.txt 改成全站 Disallow，那样会让蜘蛛彻底停止访问，恢复后重新爬也需要时间。更温和的做法是保留抓取、只放缓频率。
限速解决的是“别把我压垮”，不解决“该抓的没抓到”。如果页面本身长期无人访问、内链稀疏，再宽的配额也用不到它身上。
日志里怎么读并发
把日志按时间排序，看相邻请求的时间间隔：间隔稳定且密集，说明并发正常；如果出现成片的间隔拉长，再配合当时的响应码分布，基本可以判断是站点侧变慢，还是抓取侧主动退避。建议按小时聚合，观察是否存在固定时段的规律性波动，比如备份任务占满 IO 的那一小时。
抓取速度是站点和抓取程序之间的一个动态平衡点。站点稳定、响应快，蜘蛛自然愿意多待一会儿；站点忽快忽慢，蜘蛛就会保守行事。与其研究怎么“催”，不如先把响应时间和可用性做扎实。