1、jemeter设置
运行jemeter,选中测试计划右键,添加,线程,线程组,修改线程组名字为测试高并发
上图几个参数理解
线程数理解成并发数
ramp-up表示启动所有线程数给予的时间
循环次数表示每一个线程发出的请求数
调度器表示在规定的时间遗址进行持续并发请求直至时间到为止,同时循环此时需要选择永远
选中测试高并发,右键,添加,取样器,http请求
上图几个参数理解
协议默认http
服务器地址
路径
添加汇总报告
2、grafana相关数据图
在测试过程中我们需要将图形数据和测试数据进行对比,针对restful容器,与其相关的数据图有cpu利用率、内存使用、发送接收字节数、平均请求响应时间、每秒请求数、平均请求等待时间
这里以wrapper_hello.1容器为例
以上三个指标均是cAdvisor自带的,同时也可以使用相关命令查看这三个监控指标
docker stats wrapper_hello容器ID
除了这几个系统指标外,我们更需要对应用本身做监控,比如http请求应用时的一些指标,比如平均响应时间,平均等待时间,每秒的请求次数,请求响应时间分布、请求等待时间分布,这些指标一般来讲都是根据具体的应用自定义的,大致的方法是使用go等开发语言调用prometheus响应的api来暴漏相关的metrics
至于如何查看自定义的指标有哪些,比如我们有一个应用hello,是通过这个地址来访问的http://192.168.0.150:58080/data,在浏览器访问后,prometheus会捕捉到相关的自定义指标,这些指标可以通过监控targets地址来查看
上图标记了七个指标
这五个指标均为自定义指标,其用途如下
指标 | 说明 |
---|---|
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 | 一段周期内请求等待事件数 |
ps: 每秒请求数=总请求数(并发数) / 平均响应时间
3、restful容器直接访问
针对不同的并发数来进行测试,同时hello服务只有一个副本容器,服务器资源为2cpu5G内存
测试标准1
持续访问 5 分钟
Jmeter 客户端 10 并发数
Restful-API 容器,CPU 资源不限制
Restful-API 容器,内存 资源不限制
相关jemeter配置如下
开始模拟并发。。。。
五分钟后模拟结束,查看jemeter汇总报告
查看grafana图表数据
测试标准2
持续访问 5 分钟
Jmeter 客户端 100 并发数
Restful-API 容器,CPU 资源不限制
Restful-API 容器,内存 资源不限制
相关jemeter配置如下
从图上发现jemeter返回的响应时间大于grafana显示的数据,这是因为
测试标准3
持续访问 5 分钟
Jmeter 客户端 500 并发数
Restful-API 容器,CPU 资源不限制
Restful-API 容器,内存 资源不限制
相关jemeter配置如下
测试标准4
持续访问 5 分钟
Jmeter 客户端 1000 并发数
Restful-API 容器,CPU 资源不限制
Restful-API 容器,内存 资源不限制
相关jemeter配置如下
这个时候直接不出图了,访问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判断