多数团队在准备压测时，会把压测机理解成"一台用来发请求的服务器"，于是规格选择就变成了"越大越好"。这个理解漏掉了关键的一半：压测机同时是一个连接发生器、一个状态保持器和一个计时器。它每秒要建起几万条 TCP 连接，要在内存里同时维护几万个 socket 的收发缓冲，还要为每一个请求记录发起与结束的时间戳并做分位数统计。这三件事中的任何一件先撞到天花板，压出来的数据就已经失真了，而失真的数据往往看上去非常合理——曲线平滑、错误率不高、QPS 也稳在一个数字上，只是这个数字不是被测系统的容量，而是压测机的容量。
后端与测试同学最常遇到的三个困惑，几乎都能追溯到同一类原因。第一个是"CPU 才 30%，QPS 却怎么也上不去"，这里的 30% 通常是整机平均值，真正被打满的可能是某一个核上的软中断，也可能是端口池已经耗尽而根本发不出新连接。第二个是"并发一上万就开始报 connect timeout"，这大概率不是服务端拒绝，而是压测机本地的临时端口用尽或者 TIME_WAIT 堆积。第三个是"两台机器压出来的数不一样"，除了机器规格差异，更多时候是时钟未对齐、预热程度不同、以及两台机器所在网络位置的 RTT 不同导致的并发模型差异。
所以本文采用一条顺序固定的判断路径：先确认压测机本身不是瓶颈，再去测被测系统。具体做法是先用一次"已知静态响应"的空跑来标定压测机的上限，再进入真实场景；同一场景压三遍看数据是否稳定；压测全程同时记录压测机自身的 CPU、软中断、连接数曲线。这三件事不做完，后面所有结论都缺乏前提。
Locust 运行在 CPython 上，通过 gevent 的 monkey patch 把标准库里的阻塞调用改成协作式调度。每一个虚拟用户对应一个 greenlet，这些 greenlet 全部运行在同一个操作系统进程里，由 gevent 的事件循环统一调度。这个模型的好处是上下文切换极轻，写代码也直观；代价是单个进程只有一个事件循环，本质上只能吃满一个核，而且每个 greenlet 都要背负 Python 对象的内存开销——对象头、引用、协程栈、以及脚本自身持有的会话对象与解析结果。脚本写得越重，比如每个请求都做 JSON 解析、签名计算、响应断言和列表累积，单个虚拟用户的内存与 CPU 成本就越高，一台机器能模拟的虚拟用户数就越低。
Locust 要用满多核，靠的是多进程：官方推荐用 master 加多个 worker 的方式，或者直接用 --processes 参数在本机 fork 出与核数匹配的 worker 进程。这意味着规划容量时的单位不是"一台机器能跑多少用户"，而是"一个 worker 进程能跑多少用户 × 能开几个 worker"。反过来讲，Locust 对 CPU 单核性能高度敏感：单核越强，单个 worker 的上限越高；核数只决定能并行开几个 worker。选机器时如果只能二选一，先把单核性能顶上去，再考虑核数。
k6 由 Go 编写，测试脚本以 JavaScript 形式编写后在内置的 Go 运行时上执行，每个虚拟用户对应一个 goroutine。Go 的调度器可以把 goroutine 分发到多个操作系统线程上，天然吃多核，不需要额外做多进程编排。goroutine 的初始栈很小并且可增长，配合 Go 更紧凑的内存布局，单个虚拟用户的内存占用通常明显低于 Python greenlet 方案，因此单进程开到数万虚拟用户在社区实践中是常见的量级。
k6 对单核性能同样敏感，但敏感点不同：Go 运行时的调度、垃圾回收的停顿、以及 HTTPS 场景下的 TLS 握手计算，都会直接体现在 CPU 上。一旦脚本里开启 TLS 并且不做连接复用，握手的计算量会迅速把 CPU 打满，此时加核数的收益要大于加内存。另外要提醒一点，k6 的 --vus 与 --duration 控制的是并发虛擬用户数与持续时间，与"每秒请求数"不是一回事，两者通过响应时间相互换算，不能混用。
把两个引擎放在同一台机器上比较，量级差别主要体现在"每台机器能模拟多少虚拟用户"上：Python 协程方案通常是几千量级并依赖多进程扩展，Go 协程方案通常能到数万量级且单进程即可吃多核。但这些数字都强烈依赖脚本复杂度与目标响应时间，公开资料给出的经验值只能作为选型起点，真实上限必须由自己在本机上跑一次标定得出。正是因为这个不确定性，压测机的规格选择应该留足余量，并且优先选择可以按小时弹性扩缩的租用形态，而不是一开始就按峰值长期持有。
一条 TCP 连接由四元组唯一确定：源 IP、源端口、目的 IP、目的端口。压测机的源 IP 通常只有一个，被测服务往往也只暴露一个 IP 加一个端口，于是"源端口"成了唯一的变量。Linux 默认的临时端口范围是 net.ipv4.ip_local_port_range，常见取值为 32768 到 60999，大约两万八千个端口。也就是说，在单源 IP 对单目的 IP 加单端口的条件下，理论并发连接上限就是两万八千左右，先把整个范围放宽到 1024 到 65535 也只有六万四千多个。四万并发这个量级，撞的就是这堵墙，跟 CPU 一点关系都没有。
如果压测用的是短连接，问题会更早出现。TCP 连接关闭后，主动关闭方会进入 TIME_WAIT 状态并保留约六十秒，期间这个端口不能立即复用给新的同一四元组连接。于是一条更硬的约束出现了：新建连接的持续速率上限约等于可用端口数除以 TIME_WAIT 时长。按两万八千端口、六十秒计算，每秒只能稳定建立约四百七十条新连接，超出部分就会拿到 Cannot assign requested address 之类的报错，或者表现为 connect timeout。这就是为什么很多团队把并发调高之后，QPS 曲线不是继续上升而是直接塌陷。
可以把上限写成一条可估算的式子：可用并发连接数约等于可用源端口数乘以源 IP 数乘以目的 IP 数乘以目的端口数，然后再与另外三个约束取最小值——文件描述符上限、内核 TCP 内存能支撑的 socket 数量、以及短连接场景下端口池除以 TIME_WAIT 时长得到的建连速率。这条式子的价值在于它告诉你扩容的杠杆在哪：加源 IP 是线性放大，加目的端口或目的 IP 也是线性放大，而单纯的加 CPU 对这一项没有任何帮助。
net.ipv4.tcp_tw_reuse 的作用是允许内核在满足安全条件时，把处于 TIME_WAIT 状态的套接字复用于新的出向连接，它依赖 TCP 时间戳选项来区分新旧报文，在压测机这种纯客户端角色上开启通常是可接受的做法，能显著缓解出向连接的端口压力。net.ipv4.tcp_tw_recycle 则完全不同，它依赖对端时间戳单调递增的假设，在 NAT 环境下会把大量正常客户端误判为异常而丢连接，早已在 Linux 4.12 中被移除。现在还能在旧文档里看到"开启 tw_recycle 优化压测机"的说法，属于过时的信息，不要照做。
处置顺序建议按副作用从小到大排：先开启 HTTP keep-alive 让连接复用，把短连接变成少量长连接，这一步往往收益最大；再放宽 ip_local_port_range 到 1024 至 65535；然后按需开启 tcp_tw_reuse；如果仍然不够，给压测机增加源 IP 并在压测工具里做源地址绑定；最后才是增加压测机数量。直接跳到最后一步，会把端口问题掩盖掉，等下一轮压测规模再翻倍时又会以另一种形式冒出来。
每一个 socket 在 Linux 里都是一个文件描述符。系统级的上限由 fs.file-max 与 fs.nr_open 决定，进程级的上限由 ulimit 的 nofile 决定。通过 systemd 拉起的服务要在 unit 文件里显式配置 LimitNOFILE，通过终端手动启动的进程要确认当前 shell 的 ulimit 已经生效，这是最容易漏的一环：改了 limits.conf 却因为服务由 systemd 托管而没生效，压测跑到几千连接就开始报 too many open files。规划时按目标并发数的一到两倍设置，给日志、结果文件、管道留出余量。
每个 socket 在内核里都要占用收发缓冲区，大小由 net.ipv4.tcp_rmem 与 tcp_wmem 的最小值、默认值、最大值三个数共同决定，实际占用会在区间内随负载浮动。粗算时可以按每连接几十 KB 的内核内存估算，四万连接就是一到两个 GB 的常驻内核内存，这部分内存不可交换，且不计入压测进程的堆内存，用 top 看进程内存是看不出来的。全局上限由 net.ipv4.tcp_mem 以页为单位控制，一旦触顶内核会开始丢包，表现为重传率上升和响应时间突然变长。
net.core.somaxconn 与 listen 的 backlog 参数作用在服务端 accept 队列上，对压测机本身影响不大，除非压测机同时承担了结果收集或 mock 服务端的角色。但对被测系统，这个参数直接决定高并发下的连接排队行为，若压测机报 connect timeout 而被测系统侧的资源还很空闲，就要去检查被测端的 accept 队列是否溢出，可以用 ss -lnt 观察 Recv-Q 与 Send-Q，或者查看内核的 ListenOverflows 与 ListenDrops 计数。
出向与入向的报文都要经过网卡的 ring buffer 与内核的队列层。txqueuelen 控制发送队列长度，默认值在高 PPS 场景下偏小，可以适当调大；ring buffer 可以用 ethtool -g 查看、ethtool -G 调整，上限受硬件约束。更关键的是队列数量：单队列网卡的所有报文都会落到同一个 CPU 上处理，这是下一节要展开的问题。
网络报文的处理分成上半部与下半部，硬中断只做最紧急的收尾，真正的协议栈处理在软中断里完成，这部分 CPU 时间在 top 里显示为 si。如果压测机的网卡只有一个硬件队列，那么所有收发报文的软中断都会固定落在某一个 CPU 核上。结果是那一个核长期处于百分之百，其余核依旧空闲，整机平均 CPU 使用率看起来只有二三十，而 QPS 已经完全不再增长。这就是"CPU 才 30% 但 QPS 上不去"最常见的一个答案。
确认方法有三种，可以互相印证。用 top 观察每个核的使用率与 si 占比；用 mpstat -P ALL 1 看 %soft 列是否集中在某一个 CPU；用 cat /proc/softirqs 观察 NET_RX 与 NET_TX 的计数增长是否只落在少数几列。三者都指向同一个结论时，问题就定性了。
处置手段按有效性排列：优先启用网卡多队列 RSS，用 ethtool -l 查看当前队列数并调到与核数匹配，让中断分散到多个 CPU；其次运行 irqbalance 或手工配置中断亲和性；然后把压测进程绑定到与中断处理不同的核上，避免互相抢占；最后再考虑更换为多队列网卡或更高规格的机型。这里也要提醒：在虚拟化环境中，网卡队列数与中断绑定往往受宿主机或云平台限制，租用之前要先向服务商确认可用的队列数与是否支持多队列，避免拿到机器后才发现无法调优。
压测报告里的响应时间，绝大多数情况下是压测机在本地记录的两个时间戳之差：发起请求前取一次，收到完整响应后取一次。这意味着被测系统没有参与计时，压测机的时钟质量直接决定了这份数据的可信度。一个恒定不变的时钟偏移对单次时长的差值计算影响不大，但下面三种情况会实打实地污染数据。
第一种是压测过程中的时钟跳变。NTP 服务在偏差过大时可能选择直接步进校正，如果在压测窗口内发生步进，对应时间段内记录的响应时间会出现整段的异常值，甚至出现负值。建议使用 chrony 并让其以平滑方式 slew 校正，压测开始前用 chronyc tracking 确认同步状态与残差量级，压测期间避免触发强制同步。第二种是时钟频率漂移，晶振会随温度与负载发生百万分比级别的漂移，短时窗口内影响有限，但长时间稳定性测试里的累积效应不能忽略。第三种是调度延迟，压测进程被抢占、Go 或 Python 的垃圾回收停顿、协程排队等待调度，这些时间都会被计进"响应时间"里，它们不是服务端的处理时间，而是压测机自己的排队时间。
分布式压测里每个 worker 各自计时，最终要把多机数据合并成一条全局的分位数曲线。如果各机器的时间戳基准不一致，合并后的时间轴就是错的，峰值时段会被错位拼接，本来同一时刻发生的抖动会被摊平，本来无关的毛刺会被叠加成一个假的尖峰。更麻烦的是跨系统对账：要把压测报告与被测服务的监控指标、网关访问日志、容器平台的指标对齐看，前提就是所有机器共用同一个时间基准。因此多机压测前统一配置chrony 或 NTP 指向同一个时间源，并确认各机的偏差在可接受范围内，属于必须完成的准备工作。
把压测程序和被测服务放在同一台机器上，看似省了一台机器，实际上同时引入了两类误差。一类是资源竞争：压测进程要消耗 CPU、内存带宽、页缓存和网络协议栈的处理能力，这些资源正是被测服务需要的，被测服务因此变慢，而变慢的部分被完整计入响应时间。另一类是测量开销：压测进程占用了 CPU 之后，它自己的计时也会因为调度延迟而偏大，两个方向叠加，测出来的 P99 会显著高于真实值。此外，本机回环地址走的是与物理网卡完全不同的路径，绕过了真实网络栈的多数环节，连"网络"这一层都没测到。这种做法只能用来做冒烟验证，不能用来产出容量结论。
压测机与被测服务放在同一个内网环境里，RTT 通常在亚毫秒到几毫秒之间，公网带宽、跨运营商抖动、DNS 解析、TLS 建连的公网成本都被排除在外。这时候测出来的是应用本身的容量瓶颈：线程池、连接池、数据库、缓存、锁竞争。这个数字适合用于容量规划、版本间的回归对比、以及定位某一个具体的瓶颈点。它的缺点是过于乐观，因为真实用户并不在内网里。
压测机放在公网，走的是真实用户会走的路径，数据里自然包含了公网链路质量、跨网互通、DNS 与安全策略的影响。这个数字适合用于验收、体验评估和对外承诺前的确认。它的缺点是过于混杂：如果公网这一段本身就抖，你无法判断 P99 的劣化来自应用还是来自链路。因此两类压测的结果不能混着解读，更不能拿内网数字去对外承诺、拿公网数字去定位代码瓶颈。
并发数、吞吐与响应时间之间由利特尔法则约束：并发数约等于吞吐乘以响应时间加思考时间之和。这条式子说明了一个常被忽略的事实——同样的目标吞吐，RTT 大十倍，需要的并发连接数就大十倍，随之而来的文件描述符、socket 缓冲内存、内核 TCP 内存占用也全部大十倍。举个直观的例子：目标一万 QPS、无思考时间，RTT 一毫秒时只需要十量级的在途连接，RTT 一百毫秒时需要一千量级，RTT 一秒时就需要一万量级。跨地域压测时压测机常常先撞到自己的端口、内存与描述符上限，而不是被测系统的容量。所以跨地域压测要么降低目标吞吐，要么准备更多的压测机，两者必居其一。
所需带宽的估算式子是：每秒请求数乘以平均响应字节数再乘以八，得到的单位是比特每秒，实际规划时再上浮百分之五到十作为协议头与重传的余量。举例来说，每秒两万请求、平均响应十 KB，算出来是一点六 Gbps；每秒五万请求、平均响应二十 KB，算出来是八 Gbps。这个式子也解释了为什么大响应场景几乎总是先撞带宽：响应体一大，乘积立刻上去了。
小请求高并发压的不是带宽而是每秒报文数与每秒新建连接数。一个极简的 HTTP 事务，即便请求和响应都很小，也要产生握手、数据、确认、关闭等若干个报文，报文数远多于请求数。千兆链路上承载六十四字节小帧的理论上限约在一百四十八万 PPS 量级，实际可用值还要再打折。很多云主机与虚拟网卡的 PPS 上限会比标称带宽更早触顶，这也是按小时租用的压测机在上机后需要第一时间确认的规格项。
规划时把带宽与 PPS 各算一遍，取先到的一面作为本次压测的真实约束，然后据此反推压测机数量。如果算出来的带宽需求已经超过单台机器可用带宽，就提前拆成多台；如果算出来的 PPS 已经超过单网卡能力，就换更高规格的机型或增加机器。这一步花十分钟，能省掉后面反复排查的半天。
| 对比维度 | 单机轻量档：4 核 8G | 标准档：8–16 核 32–64G | 重型档：多台 + 万兆内网 |
|---|---|---|---|
| CPU | 单核性能决定单 worker 上限，核数只决定能开几个进程；四核适合轻量脚本与低并发，软中断容易集中在单核 | 单核性能与核数并重，可跑 master 加多 worker，进程与中断能分开绑核，TLS 密集场景余量更足 | 多机横向扩展为主，每台仍要求单核性能稳定，避免某一台拖慢整体节奏 |
| 内存 | 八 GB 需同时留给进程堆与内核 socket 缓冲，几千并发即接近上限，不适合短连接高频建连场景 | 数十 GB 可支撑数万连接的收发缓冲与结果缓存，留有余量给报告聚合与分位数统计 | 按并发目标线性拆分到各台，单机内存压力下降，重点转为结果汇总节点的内存 |
| 硬盘 | 只需容纳脚本与少量结果文件，普通 SSD 即可，注意高并发下日志写入会抢 I/O | 建议 NVMe，承载逐请求明细日志、HTML 报告与时序数据，避免落盘拖慢收尾阶段 | 各机本地高速盘写明细，汇总节点单独配置大容量盘做归档与分位数合并 |
| 网络 | 千兆内网，PPS 常早于带宽触顶；适合同机房内网压测，RTT 亚毫秒级 | 千兆到万兆内网可选，需确认网卡队列数是否可调；可承担跨机房内网压测 | 万兆内网加独立压测网段，压测流量与业务流量分离，避免干扰线上 |
| 并发规模 | 几千量级虚拟用户；短连接建连速率受端口池与 TIME_WAIT 限制更明显 | 数万量级，需配合端口范围放宽、源 IP 扩展与 fd 调优才能达到 | 十万量级以上，靠机器数量与源 IP 数量线性放大四元组空间 |
| 结果可信度 | 适合冒烟、回归与趋势对比；单点机器自身瓶颈风险高，不宜作为容量结论来源 | 完成自检与预热后可作为容量参考；需留存压测机自身资源曲线自证 | 需统一时钟源与统一压测命令，配合三遍复测后可作为对外结论依据 |
两个引擎都受单核性能约束，只是约束的形式不同。Locust 的单 worker 是单线程事件循环，单核跑不动就只能通过加进程数量绕过；k6 虽然天然多核，但调度、垃圾回收与 TLS 计算同样落在单核指令效率上。因此选型时先确认 CPU 的主频与单核跑分表现，再决定核数。核数的意义在于给中断处理、压测进程、结果聚合留下互不干扰的空间，而不是简单地"核越多并发越高"。
规划内存时最容易只算压测进程的堆，忘了内核为每个 socket 分配的收发缓冲。这部分内存不出现在进程的内存占用里，不可交换，并且随并发数线性增长。八 GB 的机器在几千并发时可能就已经吃紧，而三十二 GB 以上才能从容支撑数万连接。此外结果聚合阶段要把逐请求明细留在内存里做分位数计算，这一块的峰值也要算进去。
压测报告的价值在于可追溯，因此逐请求明细、时序数据、HTML 报告都要落盘。高并发下如果日志同步写入普通硬盘，收尾阶段会出现明显的停顿，甚至导致最后一段时间的采样丢失。建议给压测机配置 SSD 或 NVMe，明细日志采用异步或缓冲写入，压测结束后再统一聚合。重型档位下要为汇总节点单独准备大容量盘，因为各机的明细最终都会汇聚到这里。
小请求高并发场景下，先触顶的往往是每秒报文数而不是带宽。上机后第一件事应当是确认网卡的队列数是否可调、PPS 上限在哪里，而不是只看带宽标称值。内网档位还要确认与被测服务之间的 RTT 量级，跨机房内网压测时 RTT 升高会直接放大所需并发数，进而抬高内存与描述符需求。
同样是八核十六 GB，跑 Python 协程引擎与跑 Go 协程引擎能达到的虚拟用户数通常不在一个量级。这个差异不是机器的问题，而是执行模型与脚本复杂度叠加的结果。因此"这台机器能压多少并发"这个问题没有通用答案，只能用自己真实的脚本在本机跑一次标定。表格中的量级只用于选型起步，不能当作承诺值。
三档形态在硬件上的差距，最终都会落到结果可信度上。轻量档适合做冒烟、回归与趋势对比，因为它随时能起、成本可控，但用它产出的数字直接下容量结论风险很高。标准档在完成自检、预热与三遍复测后可以支撑容量判断。重型档因为涉及多机，必须额外完成时钟统一与命令一致性，才能把结果用于对外结论。换句话说，可信度不是靠机器变贵自动获得的，是靠流程补上的。
以常见的接口脚本为参照，几千量级虚拟用户、同机房内网、且已开启连接复用的场景，一台四核八 GB 的机器通常就能起步，适合冒烟、回归与日常巡检。目标是数万并发时，八到十六核配三十二到六十四 GB 是更稳的起点，同时必须完成端口范围、文件描述符与网卡队列的调优。目标超过十万并发，或者 RTT 较高导致所需连接数被大幅放大时，就必须走多机分布式，并且按四元组空间反推机器数量与源 IP 数量。
出现下面任意一种情况就应当放弃单机方案。一是目标并发数已经接近或超过单机的四元组空间；二是脚本较重，单机的 CPU 在目标并发下已经超过七成；三是需要跨地域发起流量以模拟真实地理分布；四是压测结果要用于对外承诺或容量决策，需要通过多机一致性来排除单机偶发因素的影响。分布式带来的额外成本主要是时钟统一与结果汇总，这两项在规划时就要一并安排，不能临时补救。
答案是分用途。要做容量规划与瓶颈定位，压测机应与被测机同机房内网部署，排除公网变量，让数据只反映应用本身。要做用户体验验收或对外承诺前的确认，压测机应放在真实用户所在的公网位置。两种用途不要混在一轮压测里完成，也不要拿其中一种的数字去回答另一种的问题。跨地域压测时还要提前算清楚 RTT 放大后的连接数与内存需求，否则压测机会先于被测系统崩溃。
第一件是压测机自检：先压一个已知的静态响应，比如一个固定大小的静态文件或一个只返回固定串的接口，把并发一路拉到目标值以上，确认 QPS 能随并发线性增长、压测机 CPU 与软中断没有单核打满、连接数与错误率正常。这一步通过，才说明后面的数据有测量意义。第二件是同一场景压三遍：三遍的 QPS 与 P99 应当落在可接受的波动范围内，若差异明显，说明环境或脚本存在未受控变量，先排查再继续。第三件是全程记录压测机自身的曲线：CPU 分核使用率、软中断分布、连接数、文件描述符占用、重传率，这些数据与压测报告一起归档，日后复盘时才能判断某一次结论是否可信。
这个问题没有脱离脚本的通用答案。Python 协程方案的单进程上限受事件循环调度与 Python 对象开销约束，社区公开经验常见在几千量级，并依赖多进程横向扩展。真实数字应当由你自己用真实的脚本在本机跑一次标定得出：逐步提高用户数，观察 QPS 是否仍在增长、响应时间是否开始非线性上升，那个拐点就是这台机器配这个脚本的上限。
不是。虚拟用户数与并发连接数是两回事，与每秒请求数又是另一回事。即便虚拟用户数能开上去，只要目标是短连接高频建连，端口池与 TIME_WAIT 依然会把你拉回来；只要 RTT 较大，所需连接数也会被放大。是否分布式取决于并发连接数与建连速率是否超过单机的四元组空间与 CPU 能力，而不是取决于能开多少虚拟用户。
取决于这一轮压测要回答什么问题。要回答"应用能扛多少"，放同机房内网，排除公网变量。要回答"用户感受到什么"，放真实用户所在的公网位置。两种结论不能互换使用，也不建议在同一轮压测里混合解读。若必须跨地域压测，先按目标吞吐与 RTT 估算所需连接数，再决定机器规模。
排查顺序建议这样走：先看两台机器的时钟是否同步、压测窗口内是否有人为跳变；再看两台机器与被测服务之间的 RTT 是否一致，RTT 差异会通过并发模型直接改变吞吐；然后看两台机器的预热程度与脚本参数是否完全一致，包括思考时间、超时设置与连接复用开关；最后看压测机自身的 CPU 分核使用率与软中断分布，确认其中一台没有被自己拖住。多数情况下问题出在 RTT 与参数一致性上。
在压测机这种纯客户端角色上，放宽 ip_local_port_range 与开启 tcp_tw_reuse 属于常见的调优手段，风险可控。但要注意两点：一是确认内核版本，相关参数的行为在不同版本上有差异，tcp_tw_recycle 已在 Linux 4.12 移除，不要再参考旧资料；二是如果这台机器同时承担其他业务角色，参数变更的影响面会扩大，应当先在测试环境验证。租用环境下还要确认服务商是否允许调整内核参数，以及是否提供自定义镜像或初始化脚本能力。
用算式判断即可：每秒请求数乘以平均响应字节数乘以八，再上浮百分之五到十。小响应高并发场景，百兆通常够用，但要先确认 PPS 上限而不是带宽；大响应场景，哪怕并发不高也可能把百兆打满。举例来说，每秒一万请求、平均响应二十 KB，算出来就已经超过一点五 Gbps，百兆明显不够。算完之后取带宽与 PPS 中先到的一面作为约束。
不建议直接使用。压测环境很难完整复刻线上的请求混合比例、数据分布、依赖抖动与灰度策略，压测值更适合当作上界参考。合理做法是在压测值基础上结合历史峰值与业务增长留出安全余量，再用灰度发布与线上监控逐步校正。压测结论里同时记录压测机自检数据与复测波动范围，才能让这个参考值在后续复盘时可追溯。
这取决于压测频率。常规做法是常备一到两台标准档机器用于日常回归与冒烟，遇到大版本发布或大促前的集中压测，再按小时临时扩容若干台补齐缺口，压测结束即释放。这种组合既保证了日常流程的稳定性，也避免了为一年几次的峰值长期付费。一万网络深耕 IDC 19 年（成立于 2007 年），提供自营机柜最快 1 分钟上架与按小时弹性计费的服务器方案，具体规格与计费方式以官网实时报价为准，可按需向服务商确认。
本文涉及的内核参数、协议行为与工具用法，均参考公开的 Linux 内核文档、Locust 与 k6 官方文档中关于执行模型与并发配置的说明，以及 TCP 协议关于 TIME_WAIT 与四元组约束的通行定义。文中所有并发量级与资源占用数值均为典型场景下的估算思路，用于帮助读者建立自己的计算模型，不构成对任何具体机型或具体业务的性能承诺。文中提及的"典型场景""示例架构"均为假设性说明，并非特指某一真实客户或真实测试。
服务器规格、网卡队列能力、是否支持内核参数调整、按小时计费的可用档位等与租用相关的信息，请以 https://www.idc10000.net/ 官网对应页面为准，具体以签约时最新报价与合同为准。价格主要受 CPU、内存、存储、带宽、IP 和线路影响，不同时期与不同配置差异较大，建议结合本文的估算方法先确定规模，再向服务商确认实时报价。
把全文收拢成几条可以直接执行的结论。第一，压测机是测量仪器，任何一轮压测开始前必须先证明它不是瓶颈，做法是先压一个已知静态响应做自检，再把并发拉到目标值以上看曲线是否线性。第二，并发上不去时按端口四元组、文件描述符、内核 TCP 内存、软中断单核打满这个顺序排查，而不是先看 CPU 平均值。第三，Locust 与 k6 的量级差异来自执行模型，真实上限必须由自己的脚本在本机标定，不要直接套用公开经验值。第四，时钟是测量基准，压测机必须做时间同步，多机分布式必须统一时间源，压测窗口内禁止时钟跳变。第五，内网压测与公网压测回答的是两个不同的问题，不要混着解读，跨地域压测要先算 RTT 对连接数的放大效应。第六，同场景压三遍、全程记录压测机自身曲线、归档自检数据，这三件事决定了你的结论日后能否被复盘和信任。
落到机器规格上，几千并发的同机房内网场景用四核八 GB 起步即可；数万并发选八到十六核配三十二到六十四 GB 并完成全套内核调优；十万量级或以上改走多机分布式，按四元组空间与源 IP 数量线性规划。日常回归常备一到两台，集中压测时按小时临时扩容，是多数团队成本与效率兼顾的组合。一万网络深耕 IDC 19 年（成立于 2007 年），在这一类测试环境场景中可提供配置选型参考、BGP 多线与 CN2 GIA 回国的网络选择、自营机柜最快 1 分钟上架、7×24 中文工单与平均 5 分钟响应，以及硬件故障 10 分钟自动迁移等服务支持，具体规格与承诺以官网明示项与合同为准。
如果你的团队正在规划一轮压测，却不确定压测机该按什么规格起、要不要分布式、内核参数能不能调、网卡能不能开多队列，可以把目标并发量、脚本类型、被测服务所在位置与 RTT 预期这几项信息整理出来，交给服务商做一轮选型比选。需要重点确认的四个规格项是：CPU 单核性能与核数、可用内存容量、网卡队列数与 PPS 上限、以及是否允许自定义内核参数与初始化脚本。这四项确认清楚，压测机这一侧的失真风险就控制住了一大半。
在测试环境搭建之外，一万网络还可提供免费备案协助、5–20G 免费 DDoS 防护、免费系统盘快照，以及工程师 1 对 1 部署 CUDA、cuDNN、TensorRT、PyTorch、TensorFlow 等环境的服务，方便把压测环境与其他技术验证环境放在同一批机器上统一规划。你也可以通过 https://www.idc10000.net/ 提交需求或直接联系在线客服，说明压测规模与时间窗口，由工程师协助给出可选的机型与网络方案；所有价格与规格以官网实时报价和签约合同为准。
Copyright © 2013-2020 idc10000.net. All Rights Reserved. 一万网络 科技有限公司 版权所有 深圳市科技有限公司 粤ICP备07026347号
本网站的域名注册业务代理北京新网数码信息技术有限公司的产品
