很多站長把注意力放在“蜘蛛来没来”，却很少關心“蜘蛛一次来多少”。實际上，同一時間發起的請求數量（並發）和單位時間内的請求總量（速率），直接决定了蜘蛛能在你的站点上走多深。理解這两件事，才能明白為什么有些站点抓取顺畅，有些站点總是被轻轻点一下就走了。
蜘蛛的並發不是無限的
抓取程序通常會對同一個域名维持一個连接池，同时保持若干條连接。這個數字没有公開的固定值，它和站点整体健康状况、歷史响應速度，以及抓取程序当时的资源調度都有關系。表現到日誌上，就是同一個時間段里，来自蜘蛛的請求是交织出現的，而不是一條接一條。
由此可以得出两個结论：
- 頁面响應越慢，同样的连接數能完成的抓取量越少；
- 站点一旦出現大量超时，蜘蛛會主動收窄並發，而恢复起来比降下来慢得多。
限速信号從哪里来
站点能施加的限速手段大致有三類，優先級和效果並不相同：
- 服務端返回 429 或 503。這是最直接的反馈。429 表示請求過多，503 表示服務暂时不可用。两者都會让抓取节奏明顯放缓，区別在于 503 通常會被理解為站点整体故障，影响面更大。
- robots.txt 里的 Crawl-delay。它對部分蜘蛛有效，但並非所有抓取程序都會嚴格执行，把它当作唯一手段並不稳妥。
- 控制台里的抓取速度設定。多數搜尋引擎提供了限速選項，作用范围是本站，适合在压测或大促期間临时下調。
容量准备：先算清楚能扛多少
與其被動限速，不如先算一筆帳。假设日誌里观察到蜘蛛峰值是每秒若干次請求，而這個峰值恰好出現在你最慢的一批動態頁面上，那么真實的资源消耗要按最慢那類頁面来估。一個粗略但實用的做法是：
- 挑出抓取量占比最高的 10 個 URL 模板；
- 测出它們各自的平均响應時間；
- 用峰值請求數乘以平均响應時間，估算需要的並發處理能力。
如果算出来的數字已经接近服務器上限，那就不该等蜘蛛自己撞墙，而應提前對慢頁面做缓存或静態化。
响應時間的波動比平均值更值得關注
平均值好看不代表稳定。日誌里如果出現“大部分請求 50 毫秒，少數請求 8 秒”這样的分布，說明存在慢查询或鎖竞争。這類毛刺對抓取节奏的伤害，往往比整体偏慢更大——蜘蛛遇到几次超时，就可能降低整站的抓取频率。
什么时候该主動降速
以下几種情况，主動降低抓取速度是合理選擇：
- 站点正在做資料库迁移、索引重建等重运维操作；
- 新上线的功能還没经過压测，响應時間不可预期；
- 日誌顯示磁盘 IO 或資料库连接數已经接近上限。
降速期間不要顺手把 robots.txt 改成全站 Disallow，那样會让蜘蛛彻底停止訪問，恢复後重新爬也需要時間。更温和的做法是保留抓取、只放缓频率。
限速解决的是“別把我压垮”，不解决“该抓的没抓到”。如果頁面本身長期無人訪問、内鏈稀疏，再宽的配額也用不到它身上。
日誌里怎么讀並發
把日誌按時間排序，看相邻請求的時間間隔：間隔稳定且密集，說明並發正常；如果出現成片的間隔拉長，再配合当时的响應碼分布，基本可以判断是站点侧變慢，還是抓取侧主動退避。建议按小时聚合，观察是否存在固定时段的規律性波動，比如备份任務占满 IO 的那一小时。
抓取速度是站点和抓取程序之間的一個動態平衡点。站点稳定、响應快，蜘蛛自然愿意多待一會儿；站点忽快忽慢，蜘蛛就會保守行事。與其研究怎么“催”，不如先把响應時間和可用性做扎實。