基于devops利用微服务引入三方服务-容器应用性能测试

1、jemeter设置

运行jemeter,选中测试计划右键,添加,线程,线程组,修改线程组名字为测试高并发
11ce2
上图几个参数理解
线程数理解成并发数
ramp-up表示启动所有线程数给予的时间
循环次数表示每一个线程发出的请求数
调度器表示在规定的时间遗址进行持续并发请求直至时间到为止,同时循环此时需要选择永远
选中测试高并发,右键,添加,取样器,http请求
11ce1
上图几个参数理解
协议默认http
服务器地址
路径

添加汇总报告
11ce3

2、grafana相关数据图

在测试过程中我们需要将图形数据和测试数据进行对比,针对restful容器,与其相关的数据图有cpu利用率、内存使用、发送接收字节数、平均请求响应时间、每秒请求数、平均请求等待时间
这里以wrapper_hello.1容器为例
11ce4

11ce5

11ce6

以上三个指标均是cAdvisor自带的,同时也可以使用相关命令查看这三个监控指标
docker stats wrapper_hello容器ID
除了这几个系统指标外,我们更需要对应用本身做监控,比如http请求应用时的一些指标,比如平均响应时间,平均等待时间,每秒的请求次数,请求响应时间分布、请求等待时间分布,这些指标一般来讲都是根据具体的应用自定义的,大致的方法是使用go等开发语言调用prometheus响应的api来暴漏相关的metrics

至于如何查看自定义的指标有哪些,比如我们有一个应用hello,是通过这个地址来访问的http://192.168.0.150:58080/data,在浏览器访问后,prometheus会捕捉到相关的自定义指标,这些指标可以通过监控targets地址来查看
11ce11

11ce12

上图标记了七个指标
这五个指标均为自定义指标,其用途如下

指标 说明
http_request_durations_summary_seconds_sum 一段周期内请求响应总时间
http_request_durations_summary_seconds_count 一段周期内请求事件数
http_request_durations_histogram_seconds_bucket 一段周期内请求响应时间分布
http_request_total_count 整个周期内请求数,可以理解为并发数
tracing_wait_durations_histogram_seconds_bucket 一段周期内请求等待时间分布
tracing_wait_durations_summary_seconds_sum 一段周期内请求等待总时间
tracing_wait_durations_summary_seconds_count 一段周期内请求等待事件数

11ce13

11ce14

11ce15

11ce16

11ce17

ps: 每秒请求数=总请求数(并发数) / 平均响应时间

3、restful容器直接访问

针对不同的并发数来进行测试,同时hello服务只有一个副本容器,服务器资源为2cpu5G内存

测试标准1
持续访问 5 分钟
Jmeter 客户端 10 并发数
Restful-API 容器,CPU 资源不限制
Restful-API 容器,内存 资源不限制
相关jemeter配置如下

12ce2

12ce3

开始模拟并发。。。。

五分钟后模拟结束,查看jemeter汇总报告

12ce4

查看grafana图表数据

12ce1

测试标准2
持续访问 5 分钟
Jmeter 客户端 100 并发数
Restful-API 容器,CPU 资源不限制
Restful-API 容器,内存 资源不限制
相关jemeter配置如下
12ce26

12ce25

从图上发现jemeter返回的响应时间大于grafana显示的数据,这是因为

测试标准3
持续访问 5 分钟
Jmeter 客户端 500 并发数
Restful-API 容器,CPU 资源不限制
Restful-API 容器,内存 资源不限制
相关jemeter配置如下
12ce22

12ce21

测试标准4
持续访问 5 分钟
Jmeter 客户端 1000 并发数
Restful-API 容器,CPU 资源不限制
Restful-API 容器,内存 资源不限制
相关jemeter配置如下
12ce23

这个时候直接不出图了,访问http://192.168.0.150:58080/data报错,查看service日志,出现错误

http: panic serving 10.255.0.2:59657: runtime error: invalid memory address or nil pointer dereference

这个运行时错误的原因是在"net/http"的 handler func(ResponseWriter, *Request)函数里使用了没有分配内存的指针。实际上,和C语言一样所有指针在使用前都需要做nil判断