性能专家深度解读：常见的压测模型

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

一、性能测试场景

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等负载）是否正常以及链路风险。

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

用户IP来自全球各地，如何设置ip池，避免由于负载均衡导致的流量分布不均匀。
如何按照用户地域的真实流量来分配发压机(对应k8s的pod)流量占比。
采用rps压测模型下，由于网络的抖动以及跨idc的带宽差异，不同地域相同数量的VU造成的rps差异会比较大，并且脚本的请求耗时越低，这个差异越会被放大。
排除用户自定义黑白名单限制。

需要考虑的细节点：

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

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

用户设置的rps指标直接切片到各个pod，假设每个pod误差不大并且在负载范围内，能够达到用户设置的rps指标。
优点：实现简单。
缺点：存在些许误差，容错能力、扩展能力差。
预设初始每个pod的并发用户数，每个pod上报请求次数到全局限流中间件限流，operator根据聚合的指标按照pod资源粒度进行弹性扩缩容，最终达到rps目标。
优点：具备自动容错机制，运行中支持全局动态调度。
缺点：增加了第三方组建依赖，调度实现复杂。