入口页铺出去之后，很多人的注意力都在“蜘蛛来没来”，直到某天蜘蛛真的集中来了一波，服务器先撑不住：页面超时、502、返回半截 HTML，前面做的准备工作一起打折。这篇说说入口页的承载能力该怎么看、怎么留余量。
蜘蛛抓取和普通访客不是一回事
普通访客是分散的、带浏览间隔的；蜘蛛在发现一批新 URL 之后，往往会在一段短时间里高并发地把它们扫一遍。瞬时并发可能是日常访客峰值的数倍，而单个请求通常只取 HTML，不加载图片、CSS、JS，所以带宽占用不一定高，但连接数与 IO 的消耗更集中。
如果入口页是静态文件，压力主要在带宽和连接数；如果是动态生成（读库、拼模板、请求接口），压力就转移到 CPU 和数据库上。先搞清楚自己是哪一类，再谈扩容。
优先盯住这几个指标
- 每秒请求数（RPS）：把蜘蛛 UA 和普通访客分开统计。
- 并发连接数：长连接和 keepalive 超时设置会明显影响这个数。
- 平均响应时间与 P95：平均值参考意义有限，尾部延迟才是超时的来源。
- 服务器出口带宽峰值。
- 应用进程池的排队数，以及数据库连接数。
这几项里只要有一项先到顶，其他指标再宽裕也没用。
三个最容易先崩的地方
带宽
入口页如果带了大图、字体或者未压缩的 HTML，带宽会先被打满。开启 gzip 或 br 压缩、把非必要资源去掉，往往比升级配置更直接。
应用进程与数据库
动态入口页在几百并发下就可能出现进程池排队，表现为响应时间从几十毫秒涨到几秒。给入口页做静态化缓存、把模板渲染结果缓存几分钟，是成本较低的缓解方式。
磁盘 IO 与日志
如果每个请求都写一条访问日志、再写一条业务日志，高频抓取时磁盘会先顶不住。可以考虑把蜘蛛请求的日志单独异步落盘，或者对同一 UA 的重复记录做采样。
想限速，别用错方法
- 先用 robots.txt 的 crawl-delay 表达意愿。它只是建议，部分蜘蛛不遵守，但写清楚没有坏处。
- 在服务端按 UA 或 IP 做速率限制，超过阈值返回 429 并带上 Retry-After，让抓取方自己退让。
- 不要用 503 长期挡蜘蛛，偶尔用于维护可以，长期返回容易被理解为站点不稳定。
- 也不要用 JS 跳转或延迟加载来“拖慢”蜘蛛，容易让入口页本身变得不被信任。
留多少余量比较合适
一个粗略的经验：把日常峰值的 2 到 3 倍当作目标承载，再往上留一层自动扩容或降级手段。降级方式可以是关掉非核心的统计脚本、把动态页临时切到静态缓存副本，而不是直接拒绝请求。
承载能力不是一次压测就能定下来的。入口页数量、内容更新频率、链接层级都会变，建议每隔一段时间用真实 URL 做一次小规模压力测试，看看尾部延迟有没有变化。
小结
蜘蛛池的入口页要的是“稳定可抓”，不是“极限性能”。先把带宽、连接数、进程和 IO 这几个瓶颈的监控做起来，再决定是加机器还是改结构。承载做好了不保证收录或排名，但至少不会让已经到访的蜘蛛白跑一趟。