CPU、内存和数据库最大连接数，并不能直接说明一台美国服务器能承载多少API请求。同样的请求量，缓存查询与多表事务对资源的消耗可能完全不同；同样是“并发100”，如果指在线用户、处理中请求或数据库活跃连接，得到的容量判断也会不同。

可执行的规划方法是：先用峰值请求速率和平均处理时间估算请求并发，再用数据库连接占用时间估算连接需求，最后通过混合业务压测确定满足延迟、错误率要求的持续容量。前提是明确接口比例、数据规模、响应时间目标，以及应用与数据库是否共享资源，而不是先把连接池调大再观察。

一、把“并发量”转换成能计算的业务负载

容量规划首先要分清三个量：

在线用户数不能直接换算为请求并发。用户可能长时间不操作，也可能一次打开页面就触发多个接口。更可靠的依据是业务高峰时段的访问日志，并保留短时突发特征，避免只看小时平均值。

在系统稳定、观察边界一致的情况下，可以用以下关系估算平均在途请求数：

平均在途请求数 ≈ 实际请求速率 × 平均响应时间

例如，仅作计算演示：假设应用每秒处理400个请求，应用侧平均响应时间为0.15秒，则应用侧平均在途请求约为60个。这不是某台服务器的性能结论，也不意味着把并发上限设为60就足够。

这里要注意两点：

• 公式使用平均响应时间，不能直接用P95替代并声称得到准确并发量；P95、P99主要用于判断尾延迟是否达标。
• 如果使用客户端完整响应时间，算出的是客户端观察到的在途请求，包含传输等待，不能全部视为应用执行中的请求。

对美国服务器承载的API，应同时记录客户端端到端耗时和应用内部耗时。前者决定用户体验，后者更适合定位应用与数据库的容量压力；两者不能混用。

二、数据库连接需求取决于“占用多久”，不是请求有多少

一个API请求不一定访问数据库，也不一定始终占用连接。连接通常从连接池借出，在查询或事务结束后归还；如果请求在等待外部服务时仍持有连接，这段等待也会消耗连接池容量。

可按接口类型估算平均连接占用：

平均占用连接数 ≈ Σ（某类接口RPS × 该类请求平均连接占用总时长）

其中，连接占用总时长是一次请求所有借用连接区间的累计时长。一个请求多次借还连接，需要累加；同时借用多个连接，也需要分别计入。没有访问数据库的请求按零计算。

仍以假设数据演示：总体400 RPS，其中60%的请求访问数据库，每个此类请求平均累计占用连接0.04秒，则平均占用约为：

400 × 60% × 0.04 = 9.6个连接

这只能说明平均需求约为10个连接，不能据此把连接池上限直接定为10。突发请求、慢查询、长事务和占用时间波动，都可能让瞬时需求明显高于平均值。连接池的最终大小，应由等待时间、超时率和数据库负载共同验证。

数据库允许建立多少连接，不等于能高效执行多少并发查询。增加连接池，可能缩短应用等待连接的时间，也可能让更多查询同时竞争CPU、存储和锁，反而拉长响应时间。

因此，要同时观察“已建立连接”“被应用借出的连接”和“正在执行或等待的数据库会话”，不能只看连接总数。

三、先核算连接总预算，再分配给应用实例

连接池通常属于某个进程或实例，而不是整组服务共享一个上限。应用扩容时，如果每个实例都沿用原来的连接池配置，总连接数也会随之增长。

连接预算可以按以下方式核对：

应用连接上限合计 = Σ（峰值实例数 × 每实例进程数 × 每进程相关连接池上限）

不同连接池应按实际连接的数据库分别核算。这里的峰值实例数，要包含滚动发布时新旧实例短暂共存的数量，而不只是日常运行数量。

数据库可分配给API的预算，还需要扣除后台任务、监控、管理连接、其他应用及必要预留。并且，这个预算应受压测得到的可持续数据库负载约束，不能只按数据库配置的最大连接数分配。

连接池不足时，常见表现是连接获取等待增加、请求超时，而数据库仍有余量。连接池过大时，则可能出现活跃查询上升、锁等待或I/O等待增加，吞吐却不再增长。

这意味着，扩应用实例之前，应先检查连接总预算；扩连接池之前，应先证明数据库还能承接更多并发工作。

四、用接近真实业务的测试找出容量拐点

固定测试环境和成功标准

测试环境应记录美国服务器的CPU、内存、应用实例数、连接池设置，以及数据库部署位置、版本和配置。应用与数据库共用一台服务器时，两者会争用资源，不能分别测完后简单相加。

数据规模也必须接近预计上线状态，包括表大小、索引、热点数据分布、查询返回行数和写入比例。小数据集上的快速查询，不能证明数据增长后仍有同样容量。

压测前还应确认：

• 接口组合及读写比例来自实际业务或明确预测，而不是只测最轻的接口。
• 延迟、错误率和超时目标已经确定，统计中不排除失败请求。
• 压测端资源充足，并与被测应用隔离，避免压测机先成为瓶颈。
• 写入测试使用隔离环境和可恢复数据，不误触发支付、通知等外部动作；确需影响线上数据时，应先备份、明确影响范围及恢复方案。

逐级加压，同时扫描连接池大小

先进行低负载基线测试，确认接口正确、监控完整，再按目标业务比例逐级提高请求速率。每一级都应保持到吞吐、延迟、资源及队列变化可以判断，而不是短暂冲高后立即结束。

每个压力档位，重点记录：

如果只使用固定虚拟用户数的闭环压测，服务变慢后，压测端可能因等待响应而减少新请求，掩盖过载。需要验证固定到达速率时，应使用支持该模式的压测方式，并确认实际发出的速率达到设定值。

接近目标负载后，在数据库预算范围内逐档调整连接池，一次只改变一个变量。连接池增大后，如果等待减少且数据库耗时稳定，才说明调整有效；如果查询耗时和尾延迟一起上升，就不应继续靠加连接解决。

最后，在候选容量下做持续运行测试，并补充突发流量、缓存冷启动、实例重启或发布期间的验证。

五、压测结果决定该加资源，还是先改访问方式

没有实际压测数据时，不能给出“某配置支持多少并发”的通用答案。拿到结果后，可以按以下现象解释：

可作为交付验收依据的，不是某一瞬间的最高RPS，而是：在指定接口组合和数据规模下，延迟与错误率达标、队列不持续增长、资源没有耗尽趋势的持续吞吐。

选择容量时应低于这一边界，并为业务突发、发布重叠和故障恢复留出空间。预留多少应依据峰值波动和扩容所需时间确定，不宜机械套用固定百分比。

六、从业务增长反推下一阶段容量

规划下一阶段容量，可以沿着一条可复核的链路进行：

峰值业务操作量 → 接口调用比例与RPS → 应用在途请求 → 数据库连接占用 → 压测确认的持续容量 → 实例及连接预算。

数据增长也要纳入这条链路。请求量不变，并不代表资源需求不变：表变大、热点工作集超出缓存、查询返回数据增多，都可能拉长连接占用时间，进而推高连接需求和排队时间。容量预算还应覆盖数据、索引、日志与备份的增长，避免只留计算资源、不留存储空间。

新增接口、读写比例变化、数据规模明显增长、查询或索引调整、应用进程数变化，以及运行环境更新后，都应按原有口径复测。每次保留环境、数据规模、连接池配置、压力曲线和达标结果，才能比较容量是否真正改善。

对承载API的美国服务器，合理配置不是“连接数越多越好”，而是用尽量可控的资源，在预期业务高峰下持续完成请求。先找出请求在哪里等待，再决定增加应用资源、调整连接预算，还是缩短数据库占用时间，容量选择才有依据。