蜘蛛池要做的事说起来不复杂：让入口页被反复访问，再把蜘蛛顺着链接带到目标页。但很多池子在配置抓取节奏时，只盯着“蜘蛛来得够不够多”，忽略了链路另一端的承受能力——入口页和目标页所在的服务器，能不能接住这些请求。
并发不是越高越好
抓取并发指的是同一时间允许有多少个请求在跑。把它调高，短期内请求日志会变热闹，但随之而来的往往是响应时间变长、5xx 比例上升。蜘蛛遇到慢响应或连续报错，通常会主动降低对这个站点的抓取频次，甚至在一段时间内不再回访。结果就是：你想用高并发“催”来更多蜘蛛，反而把原本稳定的抓取节奏弄丢了。
更现实的问题是，入口页本身也在同一批服务器上。如果池子的调度把资源吃满，入口页开始超时，蜘蛛拿到的就是一张打不开的门。
先摸清目标站的承受能力
在调参数之前，先花几天时间观察目标站和入口站的真实表现，比拍脑袋定数字可靠得多。
看响应时间
记录正常访问下目标页的平均响应时间，以及增加到一定并发后的变化曲线。多数站点在某个并发点之后，响应时间会从线性增长转为陡增，那个拐点就是不该越过的位置。
看错误率
把 5xx 和连接超时的比例单独统计。哪怕只有百分之几的报错，长期累积也会让蜘蛛对这个站点的评价变差。建议把错误率控制在很低的水位，一旦连续几个时段超标就降并发。
看服务器资源
CPU、内存、带宽、数据库连接数，哪一项先接近上限，就说明瓶颈在哪。动态页面的瓶颈常在数据库，静态入口页的瓶颈常在带宽。
一个粗略的倒推思路
- 测单请求耗时：在低并发下测出目标页的平均响应时间，比如 300 毫秒。
- 定可接受上限：设定一个你能接受的响应时间上限，比如不希望超过 1 秒。
- 算安全并发：理论上并发数约等于可接受上限除以单请求耗时。实际要再打个折扣，因为站点还要处理真实用户和其他来源的访问。
- 留出余量：把算出的数字再压到一半左右作为起点，先跑几天看曲线，再逐步往上加。
- 分段加量并观察：每次只调一档，观察至少一到两天，确认响应时间和错误率没有明显变化后再继续。
这套算法不精确，但它的价值在于把“感觉”换成了“先测再调”，避免一次性把并发拉到上限才发现问题。
入口页和目标页要分开限速
入口页通常是轻量的静态页，能承受较高频次的访问；目标页可能是动态生成、带查询或需要读库的页面，承受能力低得多。把两者放在同一个并发池里，等于用入口页的标准去要求目标页，很容易把目标站拖慢。
比较稳妥的做法是给它们各自设定配额：入口页可以高一些，目标页低一些，并且目标页的访问最好带上间隔，不要在同一秒内集中打过去。如果目标站是别人的站点，更要谨慎，先确认对方的 robots 规则和服务条款，别把压力转嫁给第三方。
常见误区
- 只看蜘蛛数量，不看访问质量：请求数涨了，但有效抓取没涨，等于白压服务器。
- 认为并发拉满就能催来蜘蛛：蜘蛛的抓取频次由它自己的判断决定，高并发带来的多是错误和降频。
- 一套参数套所有站点：不同站点的架构、缓存和带宽差别很大，参数需要分别标定。
- 忽略时段差异：业务高峰期的余量本来就少，抓取节奏最好避开这些时段。
- 池子和目标站同机部署：资源互相争抢，两边都跑不好，至少要把入口站和目标站分开。
落地时可以这样做
- 从低并发起步，按天或按周小幅加量，每次调整都留记录。
- 给响应时间和错误率设阈值告警，超标自动降档，而不是等人发现。
- 把限速规则写进池子的调度配置，而不是靠临时手动控制。
- 定期回看访问日志，确认爬取请求集中在真正想被抓的页面上。
- 保留可回退的配置版本，改坏了能快速恢复。
并发只是手段，不是目标。能长期稳定地拿到有效访问、同时不给站点制造麻烦，才是配置该追求的状态。任何调整都需要时间验证，不要指望一夜之间看到结果。