蜘蛛池的入口頁平时看起来没什么流量，但蜘蛛的訪問方式和真實用戶不一样：它可能在几分钟内连續請求几十上百個地址，也可能長時間保持连接。這时候頁面能不能返回、返回得快不快，取决于服務器的承载能力，而不只是頁面本身寫得好不好。
压力通常落在哪几层
蜘蛛集中来訪时，瓶颈很少是單獨的某一處，常见的顺序是這样的：
- 带宽出口：如果入口頁返回的 HTML 不大，带宽一般不是問题；但若頁面里塞了大量内联脚本、未压缩的 JSON 或大图，蜘蛛一次抓几十頁就可能把出口占满。
- 並發连接數：Web 服務器（Nginx、Apache 等）和後端進程池都有连接上限，蜘蛛並發一高，普通用戶的請求可能先被排队。
- 應用進程：PHP-FPM、Gunicorn、Java 线程池這類進程池一旦被蜘蛛占满，後續請求會等待超时，返回 502 或 504。
- 資料库與缓存：入口頁如果每次都查库、拼装模板，蜘蛛的重复請求會放大資料库压力；没有缓存时尤其明顯。
- 磁盘與日誌：高频寫入訪問日誌、频繁讀小文件，在低配机器上也可能成為隐性瓶颈。
分清是“被限流”還是“扛不住”
两種情况的表象很像，處理方式却完全相反。可以先看訪問日誌里的响應碼分布：
- 如果是自己扛不住，通常伴随 5xx 增多、响應時間整体變長，且不限蜘蛛，普通請求也慢。
- 如果是被上游或安全策略限流，往往是特定 IP 段被拒、返回 403 或 429，而其他来源正常。
把這两類记錄分開統計，比只看總請求量有用得多。
几個容易忽略的点
1. 限速设得太紧
為了防止蜘蛛压垮站点，有些运维會直接在 Nginx 里對爬虫 UA 做低速率限制。结果是蜘蛛每次只能拿到少量頁面，抓取节奏被拉長，入口頁的發現效率反而下降。限速應该以“不拖慢正常用戶”為目标，而不是越低越好。
2. 缓存里存的是错誤頁面
如果 CDN 或反向代理把一次 5xx 也缓存了，蜘蛛後續拿到的可能一直是错誤頁。检查和清理缓存規則，比反复重啟服務更有效。
3. 健康检查與蜘蛛抢资源
部分站点的监控探针频率很高，本身也占用连接。蜘蛛集中来訪时，监控告警可能先响，但根因未必是蜘蛛。
排查顺序可以參考這個
- 看响應碼分布和响應時間曲线，確認是整体變慢還是局部报错。
- 看並發连接數與進程池占用，判断是连接层還是應用层先满。
- 看資料库慢查询和缓存命中率，確認模板渲染是否是重活。
- 看带宽與出網流量，確認是否有大文件或未压缩内容。
- 最後再考虑對蜘蛛做單獨限速，且留出足够的抓取速率。
容量規划上的取舍
入口頁的目标不是让蜘蛛抓得越多越好，而是在可控的资源下保持稳定响應。宁可少放一些入口頁，也不要让整站因為一批頁面而變得不可用。
實际操作中，可以先按“每秒钟能稳定返回多少請求”估算承载上限，再决定入口頁的數量和更新频率。如果资源有限，用静態化、CDN 缓存和多机分流，通常比單纯堆配置更划算。
日常该盯的指标
- 蜘蛛請求的 P95 响應時間，而不是平均值。
- 5xx 與 429 的數量及占比。
- 進程池使用率與活跃连接數。
- 缓存命中率與回源量。
把這些指标和蜘蛛的抓取时段對照着看，往往能提前發現某段時間服務器吃不下，而不是等蜘蛛不再来訪才回头找原因。