并发压力从哪里来
蜘蛛池入口页的访问量通常不高，但分布极不均匀。一个入口页可能几天无人问津，一旦被某个搜索引擎的调度系统排进抓取队列，就会出现短时间内的集中访问。多个搜索引擎，加上同一引擎的多个抓取节点，很容易在同一秒内把请求叠在一起。这时服务器的表现往往不是慢慢变卡，而是直接超时或返回 5xx。
需要把两件事分开看：抓取总量和瞬时并发。前者决定带宽和日志体积，后者决定进程数、连接数和数据库连接是否够用。蜘蛛池场景里更常出问题的是后者。
怎么判断是并发导致的异常
- 日志中同一秒内出现多个蜘蛛 UA 请求，来源 IP 不同，但目标 URL 集中在少数几个上；
- 响应时间在抓取时段出现尖峰，非抓取时段恢复正常；
- 5xx 与超时集中在峰值前后，而不是随机分布；
- 静态资源访问正常，动态生成的入口页反而变慢。
如果异常在时间上和抓取峰值对不上，先去排查程序本身或上游接口，不要急着给蜘蛛限流。
服务器层可以调的几项
连接数与工作进程
根据实际内存给工作进程数设一个上限。宁可让少量请求短暂排队，也不要让进程被瞬间占满，导致全部请求一起变慢。入口页大多是轻量页面，进程数不必按大促规格去配。
超时时间
读超时设得过长，会让慢请求一直占着连接，后面的请求只能干等。入口页本身如果很简单，超时值不必给到几十秒，几秒内没有结果就应当释放连接。
缓存与静态化
入口页内容在短时间内基本不变，用页面缓存或直接生成静态文件，可以把这部分压力从应用层挪走。对蜘蛛来说看到的内容是一样的，只是服务器更从容。
限流要留退路
当请求确实超过承受范围，优先返回 429 或 503，并带上 Retry-After，让抓取端知道稍后再来。直接返回 403 或直接断开连接，容易被理解成长期不可访问，对后续抓取并不有利。限流规则也不要只按 IP 一刀切，同一个出口 IP 后面可能还站着大量正常访客。
限流的目的是把峰值摊平，而不是把蜘蛛挡在门外。能延迟响应就不要拒绝响应，能限制单个路径就不要封整站。
页面层顺手能做的减负
- 入口页减少同步调用外部接口，能缓存的就缓存；
- 把统计、推荐、评论这类非必要请求改成异步或延后加载；
- 避免在入口页设置跳转链，每多一跳就多一次请求；
- 图片与脚本体积控制住，蜘蛛不会等一个迟迟加载不完的页面。
值得长期盯的指标
- 入口页的 P95 响应时间，而不是平均值；
- 5xx 与超时在总请求中的比例；
- 蜘蛛 UA 请求的峰值并发数；
- 单个 URL 在短时间内的重复请求次数。
把这些数据记录下来，才能判断下一次是该继续扩资源，还是应该调整限流阈值。蜘蛛池的稳定性更多取决于日常观察和逐步微调，而不是某一次参数改动。