並發压力從哪里来
蜘蛛池入口頁的訪問量通常不高，但分布极不均匀。一個入口頁可能几天無人問津，一旦被某個搜尋引擎的調度系統排進抓取队列，就會出現短時間内的集中訪問。多個搜尋引擎，加上同一引擎的多個抓取节点，很容易在同一秒内把請求叠在一起。這时服務器的表現往往不是慢慢變卡，而是直接超时或返回 5xx。
需要把两件事分開看：抓取總量和瞬时並發。前者决定带宽和日誌体积，後者决定進程數、连接數和資料库连接是否够用。蜘蛛池场景里更常出問题的是後者。
怎么判断是並發導致的異常
- 日誌中同一秒内出現多個蜘蛛 UA 請求，来源 IP 不同，但目标 URL 集中在少數几個上；
- 响應時間在抓取时段出現尖峰，非抓取时段恢复正常；
- 5xx 與超时集中在峰值前後，而不是随机分布；
- 静態资源訪問正常，動態生成的入口頁反而變慢。
如果異常在時間上和抓取峰值對不上，先去排查程序本身或上游接口，不要急着给蜘蛛限流。
服務器层可以調的几項
连接數與工作進程
根據實际内存给工作進程數设一個上限。宁可让少量請求短暂排队，也不要让進程被瞬間占满，導致全部請求一起變慢。入口頁大多是轻量頁面，進程數不必按大促規格去配。
超时時間
讀超时设得過長，會让慢請求一直占着连接，後面的請求只能干等。入口頁本身如果很简單，超时值不必给到几十秒，几秒内没有结果就應当释放连接。
缓存與静態化
入口頁内容在短時間内基本不變，用頁面缓存或直接生成静態文件，可以把這部分压力從應用层挪走。對蜘蛛来说看到的内容是一样的，只是服務器更從容。
限流要留退路
当請求确實超過承受范围，優先返回 429 或 503，並带上 Retry-After，让抓取端知道稍後再来。直接返回 403 或直接断開连接，容易被理解成長期不可訪問，對後續抓取並不有利。限流規則也不要只按 IP 一刀切，同一個出口 IP 後面可能還站着大量正常訪客。
限流的目的是把峰值摊平，而不是把蜘蛛挡在门外。能延迟响應就不要拒绝响應，能限制單個路径就不要封整站。
頁面层顺手能做的减负
- 入口頁减少同步調用外部接口，能缓存的就缓存；
- 把統計、推荐、评论這類非必要請求改成异步或延後加载；
- 避免在入口頁設定跳轉鏈，每多一跳就多一次請求；
- 图片與脚本体积控制住，蜘蛛不會等一個迟迟加载不完的頁面。
值得長期盯的指标
- 入口頁的 P95 响應時間，而不是平均值；
- 5xx 與超时在總請求中的比例；
- 蜘蛛 UA 請求的峰值並發數；
- 單個 URL 在短時間内的重复請求次數。
把這些資料记錄下来，才能判断下一次是该繼續扩资源，還是應该調整限流阈值。蜘蛛池的稳定性更多取决于日常观察和逐步微調，而不是某一次參數改動。