入口頁铺出去之後，很多人的注意力都在“蜘蛛来没来”，直到某天蜘蛛真的集中来了一波，服務器先撑不住：頁面超时、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 這几個瓶颈的监控做起来，再决定是加机器還是改结构。承载做好了不保證收錄或排名，但至少不會让已经到訪的蜘蛛白跑一趟。