本文介绍了几大性能测试场景，对压力测试相关指标、资源的估算模型进行了解析，并深度分析了常见压测模型适用的业务场景及需考虑的技术细节，让您在使用压测验证系统能力时不再迷茫。

一、性能测试场景

1.冒烟测试

• 介绍：冒烟测试是常规的负载测试，配置为最小负载（1 个 VU），每次新增或者更改脚本，你可以利用冒烟测试作为完整性检查。
• 目的：验证测试脚本没有执行错误，验证服务端在最小负载下不会出现错误。

2.负载测试

• 介绍：负载测试主要关注在正常并发用户数或者固定 rps 下评估系统的性能，正常会采用满负载的 50%～70% 长时间的运行，中间会增加几个坡度变化来观察系统反应。
• 目的：评估系统在一定负载下的性能，确认系统的重构、更改不会造成系统严重性能问题。

3.压力测试

• 介绍：在高负载的压力下，评估系统的可用性和稳定性。压力测试下又细分为：阶梯测试（多阶梯渐进达到最大压力）、尖峰测试（短时间内极端的负载）、峰值- 测试（1 分钟的低负载，达到高负载，再消退）。
• 目的： 1）用于评估系统在用户或者吞吐量的最大容量值。 2）确认系统在高负载情况下的资源指标表现。 3）确认系统的熔断机制以及是否具备故障自动发现、恢复的模式。 4）人工干预的流程演练，如何快速定位、降级、消除故障范围。

4.浸泡测试

• 介绍：浸泡测试配置为系统容量的 80% 左右，并且尽量以小时为单位。
• 目的：在长时间处于高压力状态下，发现系统的错误和可靠性问题，通常用于快速定位内存泄漏、句柄释放、查找并发锁竞争问题。

二、性能测试场景

压测指标估算模型：
假设一个脚本执行耗时 500ms，一个线程一秒能执行 2 次，一个线程能够造成 2rps 的压力，因此工作线程数会直接影响请求的吞吐量。
假设一个脚本执行耗时 2 秒，100 个线程在第一秒能造成 100 个请求的压力，平均一秒 50 个请求，但是跟 50rps 是有根本的区别，请求的时间跨度不一致。
pod 资源估算模型：
一个并发用户=一个 VU=一个线程/协程
假设一个并发用户在 golang 运行对应是一个协程，一次脚本执行可能包括该用户的多次接口请求，一次请求需要进行 socket 连接，这里需要确认每次请求是否进行连接复用。
golang 创建一个协程资源只需 2KB 资源，协程的切换成本比较低（只需要三个寄存器的值修改 PC / SP / DX），但是如果禁用了连接复用，每次请求需要创建新的连接，对 pod 的资源消耗是极大的。

操作系统 linux 优化网络配置:

sysctl -w net.ipv4.ip_local_port_range="1024 65535"

sysctl -w net.ipv4.tcp_tw_reuse=1

sysctl -w net.ipv4.tcp_timestamps=1

ulimit -n 250000

三、常用压测模型

常用的压测模型主要包括两种，并发用户模型、固定 rps 模型。

并发用户模型用于模拟用户持续阶段增长阶段，用于验证服务端的负载不断增长或者流量减缓的前提下，性能指标的变化。

固定 rps 指标通常是由业务方根据活动波峰估算后需要达到的服务 rps 容量，因此正常只需要衡量在该 rps 压力，服务的负载（包括 latency、cpu、memory、iostat 等负载）是否正常以及链路风险。

在模拟真实流量大容量压测场景下，存在几个问题：

1. 用户 IP 来自全球各地，如何设置 ip 池，避免由于负载均衡导致的流量分布不均匀。

2. 如何按照用户地域的真实流量来分配发压机 (对应 k8s 的 pod) 流量占比。

3. 采用 rps 压测模型下，由于网络的抖动以及跨 idc 的带宽差异，不同地域相同数量的 VU 造成的 rps 差异会比较大，并且脚本的请求耗时越低，这个差异越会被放大。

4. 排除用户自定义黑白名单限制。

需要考虑的细节点：

1. 一个用户请求 10 次，10 个用户请求 1 次，同样是造成 10rps 的压力，但是对服务端的资源消耗不同，10 个用户可能存在 10 条长连接。
2. 假设真实用户是端上用户，browse 会采用 http2 连接复用技术，如何在同一条 tcp 连接进行请求的模拟、编排，当然特殊场景下可能会存在短链接场景。
3. 同一个用户（uid 标志）多次请求同一个接口，可能命中缓存，不能真实的模拟不同用户的并发场景，需要提供大量的测试数据账号。

分布式场景下，需要摸顶每个 pod（假设是 4C8G）能启动的最大并发线程/协程数。
并发用户模型，相对简单，通过均匀切片用户设置的并发用户数指标，并且按照地域流量比例下发到各个地域的 pod。
固定 rps 模型，需要设置初始的用户线程数，由于每个 pod 每个地域存在网络抖动，每个线程数能造成的 rps 压力也在浮动，存在两个技术方案——
前提：先通过短时间小范围的预压测，摸底每个地域 pod 单个线程执行脚本能造成的 rps 压力，能够提供精准的时延数据供 operator 计算调度。

1. 用户设置的 rps 指标直接切片到各个 pod，假设每个 pod 误差不大并且在负载范围内，能够达到用户设置的 rps 指标。
   优点：实现简单。
   缺点：存在些许误差，容错能力、扩展能力差。

2. 预设初始每个 pod 的并发用户数，每个 pod 上报请求次数到全局限流中间件限流，operator 根据聚合的指标按照 pod 资源粒度进行弹性扩缩容，最终达到 rps 目标。
   优点：具备自动容错机制，运行中支持全局动态调度。
   缺点：增加了第三方组建依赖，调度实现复杂。

四、优测压力测试简介

优测压力测试是一款云原生性能测试工具，可模拟百万用户发压，支持单接口、全链路及 JMeter 压测。提供多维度性能测试报告，帮助业务快速定位产品性能瓶颈、准确验证系统能力，全面提升稳定性。