美图实战分享:如何真实模拟生产流量进行服务性能压测

文章导读

服务压力测试,是评估一个服务是否优秀的过程,他不仅能让你找到你的服务哪些地方存在性能瓶颈,而且还能让你准确的去做容量评估,防止容量不足,也规避了资源浪费。
本文会带你了解以下几点内容:

  • 压测的意义
  • 压测注意点
  • 压测准备
  • 模型压测的自我理解
  • 普通压测工具
  • goreplay压测工具介绍

为什么要压测

  • 业务推广保障
  • 准确评估容量
  • 快速发现服务瓶颈
  • 极限压力测试
  • 服务迁移全链路测试

    压测需要注意哪些点(重点阅读)

  • 环境统一(基础环境、参数配置、资源型号、请求链路)
  • 压测机不能存在瓶颈
  • 压测姿势一致
  • 多次压测
  • 注意流量(如果你不想产生脏数据)
  • 注意三方依赖服务(你压测A服务,要考虑是否会顺带压测到B服务)
  • 极限压测过程中注意拐点(某些时候你qps上不去,响应时间大幅度上涨,那就说明是拐点了)

    环境统一

    这个目前我们有两种方式,第一种是新建测试环境压测,第二种是直接在生产环境压测。
    如果新建,那么我们需要考虑的点就是跟生产环境完全一致。
  • 基础环境,包括系统版本,系统参数配置
  • 软件环境,比如 Php 版本,Php 参数配置
  • 资源型号,机器的型号配置,Redis 的规格,MySql 的规格等
  • 请求链路,比如我请求的链路是经过两层 Nginx,不能在压测的时候只经过一层 Nginx。

    压测机器不能存在瓶颈

    我们之前在压测过程中,会发现当压测到一定量级后就上不去了,这时候我们一直在排查服务端是否有什么问题,包括部署资源是否足够,后端资源是否性能瓶颈,带宽是否打满等信息,绕了一圈都没有发现问题。
    最终我们发现是压测端机器性能较低,带宽打满了,最终换用了更高配的机器来进行压测。所以我们压测端一定不能成为压测计划的瓶颈。

    压测姿势一致

    简单举个例子,用ab压测的时候,需要指定线程,压测时间等参数,假如第一次用10个线程,压测10分钟,第二次用12个线程,压测20分钟

那么这样得到的数据是完全无用的。

多次压测

性能压测的数据是多次得来的,结论也是多次数据对比得出的。
由于每次压测都会有无法预知的问题,所以每次压测结束后,都需要分析结果,看看是否符合预期,比如在第二次压测,某截网络断了,那么得到的数据可能会非常差,那么这次的压测数据就不能使用。

注意流量

这个也是跟我们的压测场景有关。

  • 当我们在生产压测,那么我们肯定不能有写流量的压测,那么我们的生产数据就会脏掉,除非这些数据能够把控,在压测后能完全删除,不然是只能压测读流量。
  • 当我们在测试环境压测,这种情况可以压测全链路,不过有一个点需要关注下,当我们是服务迁移的压测,这时候生产环境跟测试环境是数据实时同步的,测试环境的脏数据也会回写到生产环境。

    注意三方依赖服务

    再举个例子,我美颜相机服务要准备压测,依赖登录、素材展示两个服务。

那么我们在压测的时候一定要去周知登录和素材的开发同学,以及让他们做好扩容准备和实时监控,实时反馈目前的一个服务状态,当有异常的时候,应立即停止压测。

极限压测过程中注意拐点

在我们压测过程中,是需要记录每次压测的结果的,比如压测结果的qps、相应时间、服务SLA等信息。当某些值在一定持续增长的压力下增长缓慢、不增长甚至降低,那么这时候你就要考虑压测是否到达了一定的拐点,类似可以做一个如下的图来简单判断拐点:
guaidian

压测前准备

  • 明确整体系统链路情况
  • 依赖资源的容量评估,确认压测的时候是否需要扩容
  • 压测部分降级方案的确认

明确整体系统链路情况

业务压测前,首先需要明确业务架构,开发需要配合运维梳理整个系统结构,开发补充业务层面,运维补充系统层面,整理出一个流量走势以及三方依赖图。明确是否跨机房、是否跨专线、是否存在网络隔离等问题。

依赖资源的容量评估

例子,A业务压测,三方依赖服务有B和C,首先要记录当前生产业务的qps,B和C业务的使用量级。假如是1000qps,B用量10台机器,C用量20台机器。那么我们压测需要压到2000qps,理论上B用20台机器,C用40台机器。

压测部分降级方案的确认

做压测工作,我们需要明确几点:

  • 我们是为了保障线上业务稳定才做的压测,所有的评估都要有预留。
  • 压测遇到的问题也正是我们上生产或者迁移后遇到的问题,所以每一个问题都需要正视。

所以针对上面两点,我们需要明确业务容量评估一定要留cache,降级方案、回退方案一定要有,防止真的出现问题。
下面是我们在压测过程中遇到的问题以及处理的过程:
reocrd

模型压测(自我理解)

这是我在压测过程中,总结的一个点,这个我可能没法用很好的词语来描述,我就用一个简单的例子来描述吧。

业务场景:简单的 Nginx + PHP 业务,容器化部署。

那么我们可以配置以下几个压测模型场景来进行压测,然后给出相应的结论:

  1. 单 Pod CPU 内存压测
  2. 单 Pod Nginx + PHP 空接口压测
  3. 单 Pod Nginx + PHP 业务单接口压测
  • 关于单 Pod CPU 内存压测,我们可以在业务部署机器上启动一个空 Pod,然后进行压测,不涉及任何业务,这里得到的结论 — 排除底层平台带来的影响。
  • 单 Pod Nginx + PHP 空接口压测,这里你可以随便写一个php接口,return 一个 OK 就行,然后进行压测,这里得到的结论 — 排除业务基础环境带来的影响比如 Nginx + PHP 等。
  • 单 Pod Nginx + PHP 业务单接口压测,这里找一个具有代表性的接口,什么是具有代表性的接口,比如这个接口是涉及到读 Redis 或者 MySql 等后端资源的。这里得到的结论 — 业务层面的一个压测结果。

经过这一轮压测之后,你能非常明确你的压测结论是否存在异议,一步步排除环境因素。

普通压测工具介绍

目前来说,我在运维过程中使用的压测工具也就是ab,wrk等,其实针对不同的场景,每一个工具都有自己的优点和缺点。

ab

  • 支持多平台
  • 默认短链接
  • 只能单进程
  • 无法控制压测时间,控制速率

wrk

  • 类unix
  • 支持多线程(更容易发挥多核的能力)
  • 支持自定义脚本
  • 默认长链接

goreploay介绍

优点

  • 可用于服务迁移前的全链路测试
  • 支持http请求录制和重放,可以复制线上请求,在压测环境重放
  • 支持http层的流量过滤,比如我只复制某一个接口的请求
  • 支持请求放大,用于性能压测
  • ……

    文档地址

    1
    2
    官方git地址:https://github.com/buger/goreplay
    官方文档:https://github.com/buger/goreplay/wiki

流量捕获

  • input-raw 捕获 HTTP 流量,需指定端口号
  • input-file 使用 –output-file 记录的文件作为输入
  • input-tcp 将多个 Gor 实例获取的流量聚集到一个 Gor 实例

流量重放

  • output-http 将流量重放到URL地址
  • output-file 将获取的流量记录如文件
  • output-tcp 将获取的流量转移至另外的 Gor 实例,与input-tcp组合使用
  • output-stdout debug 工具,将流量信息直接输出

请求过滤

  • http-allow-url 只发送正则匹配的url的请求
  • http-disallow-url 不发送正则匹配url的请求
  • http-allow-header 只发送指定head的请求
  • http-disallow-header 不发送指定head的请求
  • http-allow-method 允许的请求方法
  • http-set-header 增加http-header

流量限制

  • 随机丢弃一部分请求
    • 按照准确的qps限制
    • 按照比例限制(这里的比例,可以实现大于100%,即倍量的压测)
  • 根据Header 或者 URL 参数限制一部分请求

实战演练

goreplay安装

1
2
3
依赖go环境
wget https://github.com/buger/goreplay/releases/download/v1.0.0/gor_1.0.0_x64.tar.gz
tar xvf gor_1.0.0_x64.tar.gz

抓取流量

在公司中,我们的流量入口一般是公共代理,比如nginx等。下面例子是我在公司其中一台公共代理上抓取的流量,有以下几个说明:(给的例子是我在使用过程中的,有特殊需求的可以参考官方文档进行相应的修改)

  • 80端口
  • allow header:lb6test.meitu.com,这就是我想要压测的服务域名
  • method是get,因为post请求我们不压测,涉及到写数据
  • allowurl是我只想要抓取这个域名中a和b这两个接口的流量
  • disallow header,我要抓取token为空的,因为不为空的token涉及到登录,会连带压测我们登录的服务
  • outputfile:把抓取的流量输出为一个流量包,这样好携带
1
./goreplay  --input-raw :80 --http-allow-header 'Host: lb6test.meitu.com' -http-allow-method 'GET' -http-allow-url '/a/a.json' -http-allow-url '/b/b.json' -http-disallow-header 'Access-Token:' -output-file meitu.gor

普通输出流量

这个操作一般我们会放到单独的压测机器上进行,如果你压测的是新部署的测试环境,注意这个域名一定要在这个机器上绑定一个host,防止你压测到生产环境去了。

  • loop,循环压测,因为流量包抓取的时间是固定的,如果不循环压测,流量重放结束就会终止压测
  • disallowurl,我突然不想压测b接口的流量,那么就关闭掉。
  • outputhttp,从该压测机发起对测试环境的请求流量
    1
    ./goreplay --input-file-loop --input-file "meitu.gor" --http-disallow-url "/b/b.json" --output-http "http://lb6test.meitu.com"

    压测输出流量

    当你按照普通输出流量走一遍的时候,并且不过滤任何接口,你就会知道你这个流量包到底有多少流量,是多少 qps,假如我的meitu.gor是100 qps。
    我想要50qps
    1
    ./goreplay --input-file-loop --input-file "meitu.gor" --output-http "http://lb6test.meitu.com|50"
    我想要200qps
    这里一个操作是把流量放到1000%,那么你就可以认为这个qps是无限大的,你可以任意指定你想要的qps了。
    1
    ./goreplay --input-file-loop --input-file "meitu.gor|1000%" --output-http "http://lb6test.meitu.com|200"
    一次压测太慢,我要快速压测
    如果你觉得一个进程太慢了,那么就多启动几个进程进行压测吧
    1
    nohup ./goreplay --input-file-loop --input-file "meitu.gor" --output-http "http://lb6test.meitu.com" > /dev/null 2>&1

    输出文档

    我们压测好之后,应该输出哪些东西呢
  • 基础压测的数据
  • 极限压测的数据
  • 不同压力下的数据
  • qps,响应时间,成功率

下面是我当时压测公司某个服务记录的一些信息和描绘的图。
result1
result2
result3