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判断
