很多站点在服務器监控上看到的平均响應時間很漂亮，两三百毫秒，但抓取日誌里的抓取量就是上不去，或者一批頁面反复抓取失敗。問题往往不在平均值，而在長尾：少數請求慢到几十秒，恰好被蜘蛛碰上。
平均值藏起来的那部分請求
平均响應時間是把所有請求加總再除以數量。一個 30 秒的請求混在 99 個 200 毫秒的請求里，平均值只被拉高一点点，监控面板上看不出異常。但蜘蛛是按請求逐個走的，碰上那一個慢請求，它這一轮就可能超时断開，並把這次经歷记到這個地址上。
更實际的做法是看分位數。P95、P99 表示最慢的 5%、1% 請求需要多久，這個數值才更接近蜘蛛偶尔會遇到的真實情况。
從抓取日誌里能看出什么
- 响應時間分布：別只看平均值，按小时統計慢請求占比，看它是否集中在某些时段。
- 超时與连接中断的數量：蜘蛛主動断開，通常意味着它已经等不及了。
- 狀態碼构成：5xx、超时、连接重置混在一起，指向服務器侧，而不是頁面内容問题。
- 抓取間隔變化：同一批 URL 的抓取間隔突然拉長，往往對應這段時間响應變慢。
拖慢响應的常见环节
- 缓存未命中回源。蜘蛛走的路径和真實用戶不一定相同，命中的缓存层也可能不一样，回源一多就慢。
- 資料库慢查询。列表頁、聚合頁在資料量涨上来之後最容易暴露，頁面越大越明顯。
- 第三方接口。頁面輸出依赖外部接口，接口一慢整頁都跟着慢，而這部分耗时常常不在自己的监控里。
- 大文件與附件。图片、PDF 直出、没有走 CDN 的文件請求，會占住连接和带宽。
- 並發限流。蜘蛛並發稍高就触發全站保護，正常請求也被一起拖住。
抓取變慢和抓取失敗是两件事
頁面响應從 300 毫秒變成 3 秒，蜘蛛不會立刻放弃，但它會减少對這個目錄的抓取频次，把预算挪到別處。這個過程是渐進的，等到抓取量明顯下滑时，通常已经持續了一段時間。所以對慢的容忍度要比對错的容忍度更低，慢是失敗的先行指标。
反過来，偶尔一次失敗並不致命。蜘蛛對單個 URL 的失敗有重试机制，怕的是同一批 URL 反复失敗，让它對整個目錄降低信任。
對蜘蛛和用戶要分開看
不必专门给蜘蛛開一條通道，但限速策略應该認得它。触發保護时，與其让连接挂着不响應、讀一半直接断掉，不如明确返回 503 並带上 Retry-After，让蜘蛛知道什么时候再来。连接長時間挂起，對蜘蛛来说是最难處理的一種狀態，它既拿不到内容，也拿不到明确的信号。
如果某個頁型确實重、算得慢，可以考虑對蜘蛛返回一個内容等價但更轻的版本，或者把它拆成多個更小的頁面，而不是让它每次都走完整條重鏈路。
排查顺序
先從抓取日誌里挑出响應最慢的一批 URL，按目錄归類，看它們是不是集中在同一類模板；再去服務器侧對照那段時間的慢查询、缓存命中率和外部接口耗时。多數情况下問题會落到某一两個頁型上，而不是全站均匀變慢。找到頁型之後，處理方式通常是缓存、异步化或者拆分，而不是整体加机器。
蜘蛛感受到的站点速度，是它自己那批請求的分布，不是监控面板上那條平均线。
在监控里加一條 P95 或 P99 的曲线，成本不高，却能在慢請求還没變成抓取失敗之前提前發現問题。