蜘蛛池要做的事说起来不复杂：让入口頁被反复訪問，再把蜘蛛顺着連結带到目标頁。但很多池子在配置抓取节奏时，只盯着“蜘蛛来得够不够多”，忽略了鏈路另一端的承受能力——入口頁和目标頁所在的服務器，能不能接住這些請求。
並發不是越高越好
抓取並發指的是同一時間允许有多少個請求在跑。把它調高，短期内請求日誌會變热闹，但随之而来的往往是响應時間變長、5xx 比例上升。蜘蛛遇到慢响應或连續报错，通常會主動降低對這個站点的抓取频次，甚至在一段時間内不再回訪。结果就是：你想用高並發“催”来更多蜘蛛，反而把原本稳定的抓取节奏弄丢了。
更現實的問题是，入口頁本身也在同一批服務器上。如果池子的調度把资源吃满，入口頁開始超时，蜘蛛拿到的就是一張打不開的门。
先摸清目标站的承受能力
在調參數之前，先花几天時間观察目标站和入口站的真實表現，比拍脑袋定數字可靠得多。
看响應時間
记錄正常訪問下目标頁的平均响應時間，以及增加到一定並發後的變化曲线。多數站点在某個並發点之後，响應時間會從线性增長轉為陡增，那個拐点就是不该越過的位置。
看错誤率
把 5xx 和连接超时的比例單獨統計。哪怕只有百分之几的报错，長期累积也會让蜘蛛對這個站点的评價變差。建议把错誤率控制在很低的水位，一旦连續几個时段超标就降並發。
看服務器资源
CPU、内存、带宽、資料库连接數，哪一項先接近上限，就說明瓶颈在哪。動態頁面的瓶颈常在資料库，静態入口頁的瓶颈常在带宽。
一個粗略的倒推思路
- 测單請求耗时：在低並發下测出目标頁的平均响應時間，比如 300 毫秒。
- 定可接受上限：设定一個你能接受的响應時間上限，比如不希望超過 1 秒。
- 算安全並發：理论上並發數约等于可接受上限除以單請求耗时。實际要再打個折扣，因為站点還要處理真實用戶和其他来源的訪問。
- 留出余量：把算出的數字再压到一半左右作為起点，先跑几天看曲线，再逐步往上加。
- 分段加量並观察：每次只調一档，观察至少一到两天，確認响應時間和错誤率没有明顯變化後再繼續。
這套算法不精确，但它的價值在于把“感觉”換成了“先测再調”，避免一次性把並發拉到上限才發現問题。
入口頁和目标頁要分開限速
入口頁通常是轻量的静態頁，能承受較高频次的訪問；目标頁可能是動態生成、带查询或需要讀库的頁面，承受能力低得多。把两者放在同一個並發池里，等于用入口頁的标准去要求目标頁，很容易把目标站拖慢。
比較稳妥的做法是给它們各自设定配額：入口頁可以高一些，目标頁低一些，並且目标頁的訪問最好带上間隔，不要在同一秒内集中打過去。如果目标站是別人的站点，更要谨慎，先確認對方的 robots 規則和服務條款，別把压力轉嫁给第三方。
常见誤区
- 只看蜘蛛數量，不看訪問质量：請求數涨了，但有效抓取没涨，等于白压服務器。
- 認為並發拉满就能催来蜘蛛：蜘蛛的抓取频次由它自己的判断决定，高並發带来的多是错誤和降频。
- 一套參數套所有站点：不同站点的架构、缓存和带宽差別很大，參數需要分別标定。
- 忽略时段差异：业務高峰期的余量本来就少，抓取节奏最好避開這些时段。
- 池子和目标站同机部署：资源互相争抢，两邊都跑不好，至少要把入口站和目标站分開。
落地时可以這样做
- 從低並發起步，按天或按周小幅加量，每次調整都留记錄。
- 给响應時間和错誤率设阈值告警，超标自動降档，而不是等人發現。
- 把限速規則寫進池子的調度配置，而不是靠临时手動控制。
- 定期回看訪問日誌，確認爬取請求集中在真正想被抓的頁面上。
- 保留可回退的配置版本，改坏了能快速恢复。
並發只是手段，不是目标。能長期稳定地拿到有效訪問、同时不给站点制造麻烦，才是配置该追求的狀態。任何調整都需要時間驗證，不要指望一夜之間看到结果。