压力测试的相关介绍,涵盖函数的benchmark、接口的压测、简单服务压测、分布式系统压测及压测工具的开发相关内容。

什么是压测

压测是一种通过人为的手段,以验证软硬件是否符合相关性能要求,找出软硬件容量上限等为目的的测试行为。

通常,进行压测主要来源于:

  • 用户需求
  • 资源规划
  • 持续改进

举一个简单的例子,在移动运营商进行5G网络部署的时候,在一个5万人口的小区架设几个基站,它需要知道每个基站服务的范围,服务的用户数,上网带宽等等数据,没有这些数据,它就无法进行有效的基站规划,这时候就需要进行测试。

再比如,淘宝双十一,各项服务是否磨合就绪,流量上来之后能否有效限量,避免出现雪崩,诸如此类的问题都需要在之前通过压测来验证。

上面说的都是比较大型的系统,压测的场景也比较复杂,实际上,压测可以从很小的函数开始,而且大部分情况下,我们只需要关注函数和接口就够了。

压测从分析系统开始

首先需要明确系统的关键指标, 如:

  • DNS服务每秒可以响应20W个查询请求
  • 95%的查询请求响应时间在5ms以内
  • 当请求量达到25W每秒时,其中的20W请求能正确处理,响应时间波动在5%以内

其次需要明确资源限制,如:

  • 硬件:如网口速率,CPU核心数,内存大小,是否SSD,交换机速率等
  • OS:如内核版本,是否支持zero copy,是否支持bbr等
  • 应用软件:如asyncio,coroutine,GIL,是否采用DPDK等

接下来就需要定义压测的场景,如:

  • A类内部DNS请求场景
  • A类转发外部DNS请求场景
  • AAAA类内部DNS请求场景

函数Benchmark

辛辛苦苦写了个xxtea的编解码函数,结果写完的时候发现github上已经有一个实现了,而且功能完全满足,这时候是不是很沮丧?别急,先喝杯茶,跑下benchmark,如果咱的实现性能更优,那就不用现成的,或者给人提个pull request。

像go这样的语言,内置了对benchmark的支持,实现起来很方便,只要写一个名字为Benchmark开头的单元测试就可以了,如:

BenchmarkEncrypt(b *testing.B) {
	data := []byte("gvhaerutq vnp3h 7-q324bv571 5adhfadddf")
	key := []byte("1231241adfsdfh3456sadfasdf")

	for i := 0; i < b.N; i++ {
		Encrypt(data, key)
	}
}

这时候执行go test -benchmem -bench=. ./... -run=none就可以得到类似下面的结果:

➜  xxtea git:(master) go test -benchmem -bench=. ./... -run=none
goos: darwin
goarch: amd64
pkg: github.com/feiyuw/xxtea
BenchmarkEncrypt-8               3000000               531 ns/op             112 B/op          3 allocs/op
BenchmarkXXTeaGoEncrypt-8        2000000               650 ns/op             128 B/op          3 allocs/op
BenchmarkDecrypt-8               3000000               545 ns/op             112 B/op          3 allocs/op
BenchmarkXXTeaGoDecrypt-8        3000000               581 ns/op             128 B/op          3 allocs/op
PASS
ok  	github.com/feiyuw/xxtea	8.772s

上面的输出可以看到:

  • 操作系统是MacOS,CPU是64为的Intel的(goos,goarch)
  • 测试的包名为:github.com/feiyuw/xxtea
  • 共测试了4个用例,其中类似531 ns/op表示每个函数调用消耗了531 ns的CPU时间,112 B/op表示每个函数调用消耗了112字节的内存,3 allocs/op表示在每个函数调用期间发生了3次内存分配

从这个benchmark结果我们可以看到:

  • 我们的Encrypt函数比另一个实现快了近20%,内存节省了16个字节
  • 我们的Decrypt函数快了6%左右,内存消耗少了16个字节

这个时候我们就可以做决定了。

对一个接口的压测

这可能是最经常见到的压测形态了,用于这类压测的工具有很多,如:

  • ab
  • hey
  • wrk
  • dnsperf

等等,这类压测的特点是:

  • 接口单一
  • 对相同数据不敏感

如,我用hey压测了我的一个python应用的version接口,得到了如下的结果:

➜  pef git:(master) ✗ hey -n 100000 -c 200 http://127.0.0.1:19898/api/v1/version

Summary:
  Total:        19.0831 secs
  Slowest:      0.1048 secs
  Fastest:      0.0003 secs
  Average:      0.0372 secs
  Requests/sec: 5240.2282

  Total data:   1999960 bytes
  Size/request: 20 bytes
...

从结果可以看到:

  • 我们的服务每秒可以处理5240个请求,平均每个请求的响应时间为0.0372秒,最慢的请求花了0.1048秒
  • 我们总共发了10000个请求,模拟了200个用户

需要注意的是:

  • 测试数据对接口的影响需要明确,特别是对数据有校验和不同分支逻辑的情况
  • 相同数据多次请求是否有缓存需要明确,避免得到与实际情况偏差过大的结果
  • 对一些高性能的接口,需要考虑硬件的影响,看看是否达到了硬件瓶颈,如网口带宽等等

对一个简单服务的压测

真实世界的用户场景都是比较复杂的,是复合的场景。比如:

  • 用户获取了设备指纹之后,再去验证滑动验证码
  • 用户登陆后,浏览博客和论坛内容

这种情况下通过简单的一条命令就很难测试了,我们往往需要编写代码构造测试场景,从上古时期的loadrunner,到之后的jmeter,再到现在的locust之流,都是为了解决这类问题应运而生的。

locust场景

这类压测的特点是:

  • 针对特定场景
  • 存在一定的业务逻辑
  • 数据有相关性

从locust官网抄了个例子下来:

from locust import HttpLocust, TaskSet, task

class WebsiteTasks(TaskSet):
    def on_start(self):
        self.client.post("/login", {
            "username": "test_user",
            "password": ""
        })

    @task
    def index(self):
        self.client.get("/")

    @task
    def about(self):
        self.client.get("/about/")

class WebsiteUser(HttpLocust):
    task_set = WebsiteTasks
    min_wait = 5000
    max_wait = 15000

这个例子中,每个虚拟用户会先进行login,然后按照比例访问主页和about页面,每个请求的间隔在5s到15s之间,从一定程度上保证虚拟用户尽可能地模拟真实用户的行为。

大型分布式系统的压测

当系统大到一定程度,上面的方法就行不通了,因为数据关联性太多,逻辑太复杂,导致几乎没有好的办法模拟。这个时候就得需要一些别的手段了。

常见的一个方法叫流量回放,就是把线上的流量按照一定比例放大,导入到测试系统中,然后观察测试系统的反应情况,有些服务能用这类办法,但也有不行的,比如涉及到P2P行为的系统就很难通过流量回放来模拟。

此时的方法概括起来有:

  • 终端埋点
  • 运维控制
  • 数据采集
  • 全景监控

终端埋点是指通过在网页、app等地方添加钩子,接收特定的指令来做一些事情,比如访问一个页面等等(很多基调公司就是这么做的)。

运维控制是指可以通过运维接口让特定的终端来参与到测试中来,进行模拟的页面访问等操作,这种方式让测试更贴近于真实。

数据采集是指通过一定的机制把这些测试数据都采集上来,包括终端的请求响应情况等等。

全景监控是指通过对采集的数据的汇总和可视化,达到对整个服务全景情况的监控目的,以获取压测结果。

压测工具的设计思路

设计一个像locust那样的压测工具,其核心理念与做一个高性能的应用是类似的,概括起来,基本功能包括:

  • 组织场景
  • 构造数据
  • 模拟请求
  • 采集数据
  • 结果汇总

也就是说,能通过一些手段(如python脚本)把测试场景组织起来,构造测试数据,模拟HTTP(或其他协议)的请求,然后在工具层面采集数据,并将结果汇总展示。

除此之外,为了保证性能和可用性,往往还需要支持:

  • 水平扩展
  • 性能监控
  • 分析结果
  • 报表展示

水平扩展通常是一个master多个slave的模式,可以让多台机器参与压力测试,以避免因为施压机性能的问题而无法找出应用瓶颈。

性能监控是指除了获取QPS,响应时间这样的数据之外,我们通常还需要关注被测应用所在机器的CPU、内存、网络IO等数据,所以在压测时候需要同步收集这类数据。

分析结果对于收集到的数据进行预分析,提前过滤出可能的问题。

报表展示是对于测试情况能以图表的形式直观的展示。

从实现上来说,压测工具通常会:

  1. 读取测试脚本,编译为工具可识别的流程描述
  2. 把每个虚拟用户抽象为一个协程(或线程)按照测试脚本描述进行执行,每次执行完毕都会把结果汇报给压测工具的数据统计协程(或线程)
  3. 数据统计协程将所有虚拟用户的结果加以汇总,实时展示到报表界面上
  4. 报表界面在一个单独协程中,从统计协程消费数据,并通过某种方式(如web)加以展示

压测工具实现示例

在locust基础上实现了一个简单的压测工具,严格来说是slave端,它的具体思路如下:

  • 复用locust的master端
  • 基于locust golang sdk二次开发,解决locust性能不佳的问题
  • 具体的业务逻辑在slave中实现,master只负责调度和汇总数据

大致架构如下图:

pef架构图

工作流程:

  • Start master (locust)
  • Start slave
  • Loop:
    • Master hatching
    • Slave.OnStart()
    • Slave running test, sync result to master
    • Master show stats
    • Master stop spawning
    • Slave.OnStop()
  • Stop Slave
  • Stop Master

实现注意点:

  • 对象池
  • 连接复用
  • Buffered Channel

这几个注意点基本都是为了性能考虑的,使用对象池减少GC,连接复用减少建连的开销,Buffered Channel让数据消费更顺畅(即不要用共享内存来通信,而是用通信来共享内存),同时能够解决掉一些高并发执行过程中的抖动问题。

参考