美国三网精品服务器是指哪三网？并发与吞吐测试如何设定容量边界

“美国三网精品服务器”里的“三网”，通常是指中国电信、中国联通和中国移动。这里的“三网”是从中国大陆访问美国服务器时所对应的三类主要接入网络，并不是指美国境内固定存在的三家网络运营商。“精品”也不是统一的技术标准，实际应通过三网访问时的延迟、丢包、抖动、吞吐和稳定性来验证。

容量判断不能只看服务器标称带宽，也不能把“同时在线人数”直接等同于“并发请求数”。更可靠的做法是：分别从电信、联通、移动网络发起测试，在相同业务接口、相同数据量和相同时间窗口下，记录响应时间、请求吞吐、错误率以及CPU、内存、网络和I/O变化，再以最弱的一条访问路径和最先饱和的资源作为容量边界。

先明确三网测试对象和业务目标

三网分别代表什么

测试客户端最好分别位于三类真实接入网络中，至少保证出口运营商明确。三组客户端访问同一个目标IP、同一个协议和同一个业务接口，避免因为DNS解析到不同地址、IPv4和IPv6路径不同或缓存状态不同而造成误判。

如果业务用户主要集中在某一类网络，可以提高该网络测试结果的权重；如果用户来源分散，则容量边界应以三网中最差但仍满足业务目标的一组数据为准。某一网络延迟更高，不一定说明服务器本身资源不足，也可能是访问路径、时间段、丢包或回程拥塞造成的，因此需要把网络指标和服务器资源指标放在一起分析。

先定义可接受的结果

压测前要先写出可执行的服务目标，而不是测试完成后再挑选好看的数据。例如：

• p95响应时间不超过500毫秒；
• 错误率低于1%；
• 超时率接近于零；
• CPU长时间运行不超过预设阈值；
• 内存没有持续下降，且不发生交换；
• 磁盘I/O等待不会随负载持续上升；
• 三网访问结果不出现单独一组明显失控的情况。

这些数值只是便于说明的参考目标，不是所有业务都必须采用的固定标准。接口类型不同，静态内容、动态查询、文件传输和实时交互的合理阈值也不同。

并发、吞吐和响应时间不是同一个概念

并发连接与并发请求

“并发1000”可能有几种完全不同的含义：

• 同时保持1000条TCP连接；
• 同时有1000个请求正在处理；
• 每秒发起1000个请求；
• 有1000名用户在线，但每名用户每隔几秒才请求一次。

容量估算时，应优先记录每秒请求数（RPS）、正在处理的请求数、活跃连接数和请求响应时间。在线人数只能通过用户行为模型换算，不能直接当成服务器处理能力。

吞吐量也不只有一种表达方式：

• 请求吞吐：每秒完成多少个请求；
• 数据吞吐：每秒传输多少字节；
• 有效吞吐：扣除错误、超时和重传影响后，用户真正获得的数据量。

对于小接口，请求数通常是主要约束；对于图片、下载或较大接口，出口带宽和单连接传输速度可能先成为瓶颈。

用响应时间估算活跃请求数

可以使用排队系统中常用的近似关系：

\[ 并发处理请求数 \approx 每秒请求数 \times 平均响应时间（秒） \]

例如，一个接口稳定处理80 RPS，平均响应时间为0.4秒，则正在处理的请求约为：

\[ 80 \times 0.4 = 32 \]

这并不代表只需要配置32个连接。突发流量、响应时间长尾、Keep-Alive连接和客户端重试都会增加连接数量。因此压测时仍要使用高于平均活跃请求数的连接并发，并单独观察连接是否堆积。

p50表示中位响应时间，p95表示95%的请求都不超过该值，p99则更容易暴露队列、I/O抖动和偶发慢请求。容量边界不应只看平均值。平均响应时间很低，但p99已经明显升高，通常说明系统开始接近排队或资源争用状态。

用请求量估算带宽需求

带宽的初步估算可以使用：

\[ 所需带宽 \approx RPS \times 平均请求总字节数 \times 8 \times 协议及波动系数 \]

假设一个接口每次请求和响应合计约200KB，目标为150 RPS，协议及波动系数按1.15计算：

\[ 150 \times 200KB \times 8 \times 1.15 \approx 276Mbps \]

这里的200KB应尽量来自业务日志或接口实际响应大小，而不是只看HTML首页大小。压缩、TLS、请求头、响应头、重试和错误请求都会影响最终流量。若业务存在突发峰值，还要在此基础上留出增长余量。

测试环境要保持一致

一次有参考价值的测试，至少需要固定以下条件：

1. 目标服务器IP和协议版本保持一致，IPv4与IPv6分开测试。
2. 三类客户端访问相同的URL、端口和请求方法。
3. 明确接口是否命中缓存，动态接口是否访问数据库或其他后端。
4. 固定请求体、响应数据量、认证方式和连接复用策略。
5. 客户端自身不能先达到CPU、带宽或文件描述符上限。
6. 每个负载档位先预热，再保持足够时间，不能用刚启动几秒的结果代表稳定能力。
7. 电信、联通、移动分别记录，不把三组结果混成一个平均值。

“精品”网络质量也不能只通过一次测速判断。可以在三类接入网络中分别观察TCP连接建立时间、TLS建立时间、首字节时间、完整响应时间、丢包和重传。路由追踪只适合辅助定位，不能因为中间某一跳显示高延迟，就直接认定最终业务一定慢；应以目标地址的最终响应和应用层结果为准。

测试步骤：先测网络，再测业务并发

第一步：进行基础连通性和吞吐测试

基础吞吐测试可以帮助判断服务器出口与访问路径是否已经成为限制因素。以下命令适用于安装了 iperf3 的Linux环境。

服务端临时启动监听：

iperf3 -s -p 5001

在电信、联通、移动测试客户端分别执行：

iperf3 -c SERVER_IP -p 5001 -P 4 -t 60 -i 1

其中：

• -P 4表示使用4条并行流，可根据实际业务连接特征调整；
• -t 60表示持续60秒；
• -i 1表示每秒输出一次结果；
• SERVER_IP应替换为待测试服务器地址。

如果业务使用IPv6，应使用对应IPv6地址单独测试，例如：

iperf3 -6 -c SERVER_IPV6 -p 5001 -P 4 -t 60 -i 1

该测试会消耗服务器和客户端的网络资源，不建议直接在高峰生产环境长时间运行。测试端口应只对指定测试来源开放，测试结束后停止监听并撤销临时访问权限，避免测试端口长期暴露。不要把一组客户端的吞吐结果直接当作三网用户的共同体验。

第二步：测量服务器资源基线

在业务压测前，先记录空载或低负载状态。Linux环境中可以使用以下只读监控命令：

vmstat 1

iostat -xz 1

sar -n DEV 1

ss -s

这些命令通常分别用于观察运行队列、内存和上下文切换，磁盘设备延迟与利用率，网卡流量，以及连接总量。不同Linux发行版预装工具可能不同，命令不可用时应先核对工具是否已安装，不要直接套用不适配的参数。

建议同时记录：

• CPU总使用率以及是否存在单核长期满载；
• 内存使用量、可用内存和交换区活动；
• 网卡接收与发送速率；
• 磁盘利用率、平均等待时间和队列长度；
• TCP连接数、连接建立失败和超时；
• 应用进程的请求队列和错误日志。

第三步：用阶梯负载观察拐点

业务接口测试应从低负载开始逐步增加，而不是一开始就把连接数拉满。一个可操作的阶梯可以是50、100、150、200 RPS，每个档位预热1至2分钟，再稳定运行5分钟左右。正式业务可能存在突发流量，还应增加短时突发测试，但突发测试结果不能替代稳定负载结果。

如果使用wrk测试只读接口，命令可以是：

wrk -t4 -c200 -d5m --latency https://example.com/health

该命令会尽可能快速地产生请求，-c200是连接并发数，并不等于固定的200 RPS。/health只是示例，正式测试应选择不会修改数据的业务接口。涉及写入、扣减、下单或重复提交的接口，不能直接用无状态压测命令重放，否则会污染业务数据。

当测试目标是固定RPS而不是“尽可能压满”时，可以采用支持到达率控制的工具。例如以下配置用于产生约80 RPS的持续请求：

import http from 'k6/http';
import { check } from 'k6';

export const options = {
  scenarios: {
    steady_load: {
      executor: 'constant-arrival-rate',
      rate: 80,
      timeUnit: '1s',
      duration: '5m',
      preAllocatedVUs: 100,
      maxVUs: 300
    }
  },
  thresholds: {
    http_req_duration: ['p(95)<500'],
    http_req_failed: ['rate<0.01']
  }
};

export default function () {
  const response = http.get('https://example.com/read-only-endpoint');
  check(response, {
    'status is successful': (r) => r.status >= 200 && r.status < 400
  });
}

如果生成端CPU、网卡或连接数先达到上限，测试结果就不能代表服务器容量，应增加生成端能力或降低单个客户端的负载。只有确认压力确实到达目标服务器，延迟和错误率才有解释价值。

如何解释一次压测结果

以下是一组用于说明分析方法的示例数据，数值不是特定服务器的实测结果。接口平均请求总大小约为200KB，目标p95响应时间为500毫秒，错误率目标低于1%。

从这组数据可以看到，150 RPS时p95仍低于500毫秒，但p99和CPU已经接近风险区；200 RPS时响应时间、错误率和资源使用率同时恶化，说明系统已经越过稳定边界。若把150 RPS作为未经增长预留的测试边界，按30%的增长余量折算，当前计划负载宜控制在：

\[ 150 \div 1.3 \approx 115RPS \]

这并不是说115 RPS是所有业务的固定安全值，而是说明“测试峰值”和“生产计划值”不应设置为同一个数。

常见指标组合及含义

• CPU持续接近满载，p95和p99同时上升：通常是计算能力或应用处理队列先达到限制。
• CPU不高，但I/O等待、p99和超时持续升高：应检查数据读取、日志写入或其他磁盘等待，而不是继续增加并发。
• 服务器CPU和I/O都正常，但出口流量接近上限：可能是带宽成为瓶颈，增加请求只会带来排队和重传。
• 服务器资源正常，只有某一接入网络响应变差：应分别核对该网络的丢包、连接建立时间、路由变化和测试时间段。
• 客户端CPU或网卡先满，服务器数据却很平稳：压力生成端不足，当前结果不能作为服务器容量结论。
• 平均响应时间正常，但p99突然扩大：通常是突发排队、连接复用异常、I/O抖动或后端偶发慢请求，需要延长稳定测试时间。

三网结果如何转化为容量边界

同一业务在三类网络中的示例结果如下：

如果业务目标是p95不超过500毫秒、错误率低于1%，这三组结果都暂时满足目标，容量评估应以中国移动这一组较弱结果为参考，而不能用电信的280Mbps作为所有用户的可用容量。

如果业务把p95目标收紧到300毫秒，中国联通和中国移动就需要进一步优化或降低计划负载。此时“精品”不能靠名称判断，而要看三网是否都在实际业务目标内。

可以将最终边界表示为：

\[ 可用容量 = \frac{\min（电信边界、联通边界、移动边界、CPU边界、I/O边界、网络边界）}{1+预期增长比例} \]

其中每一个“边界”都必须是在错误率和响应时间满足目标时得到的最大稳定值。如果预计未来流量增加30%，就不能简单把当前峰值当作上线容量；应使用测试边界除以1.3，或者在测试阶段直接压到预计峰值的1.3倍以上。

复测条件与最终判断

出现以下变化时，应重新进行三网测试，而不能沿用旧结果：

• 业务接口响应体积明显增加；
• 应用版本、查询逻辑或缓存策略发生变化；
• 用户请求比例或访问时间段变化；
• 服务器出口带宽、IP地址或协议版本变化；
• 某一网络的延迟、丢包或连接建立时间出现持续变化；
• CPU、内存、磁盘或连接数达到原测试的高位；
• 生产环境的峰值RPS接近此前的计划容量。

复测时至少保留测试时间、接入网络、目标IP、请求大小、并发模型、稳定时长、p50/p95/p99、错误率以及CPU、内存、I/O和带宽数据。每个网络建议重复多轮，并区分短时突发和持续稳定负载。

最终的容量判断应同时满足三个条件：三网访问结果均达到业务响应目标；最先饱和的服务器资源仍留有增长余量；测试客户端没有成为瓶颈。只要其中任一条件不满足，就应把该项作为当前容量边界，而不是用三网平均值掩盖最弱环节。