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

一、性能测试场景

1.冒烟测试

2.负载测试

3.压力测试

4.浸泡测试

二、性能测试场景

压测指标估算模型
假设一个脚本执行耗时 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 压测。提供多维度性能测试报告,帮助业务快速定位产品性能瓶颈、准确验证系统能力,全面提升稳定性。


↙↙↙阅读原文可查看相关链接,并与作者交流