jmeter---最大吞吐量测试
平常项目性能测试，并没有做过最大吞吐量的测试，也不知道怎么测，最近学习了一下，然后找了个项目执行了一下看看（用的是项目中的某个查询接口进行测试的），以下是记录的
- 使用的工具：jmeter
- jmeter脚本中会用到的组件：用户定义的变量、http信息头管理器、线程组、http请求、响应断言、jp@gc-throughput shapping timer、jp@gc-transactions second
- 介绍一下jp@gc-throughput shapping timer、jp@gc-transactions second 这两个，其他组件比较熟悉，就不讲解了
3.1、jp@gc-throughput shapping timer，如下
3.2、jp@gc-transactions per second，一种监听器组件，图形化的方式显示每秒事务数
4、测试吞吐量极限的方法
4.1、被测请求，进行单并发持续跑，通过聚合报告，查看throughput值，此值稳定变化不大的情况下，记录此值为N，即单并发下每秒的请求数。
4.2、假设预估此请求最大吞吐量是100个/s，而4.1中测的throughput值是10个/s,
如果想达到100个/s的吞吐量， 那大概需要10个并发（即10并发*10个/s=100个/s）
即设置线程组的线程数为大于10的值（比如设置成20）
4.3、请求下方添加jp@gc-throughput shapping timer组件，配置start rps、end rps 、duration参数，配置完后，下方会图形化显示在此配置情况下，不同时间点的吞吐量值
4.4、为了保证执行过程中，请求执行成功不出错，需要添加响应断言，如下
4.5、在线程组下方添加jp@gc-transactions second
4.6、最后执行此脚本，查看不同时间点，吞吐量的变换。从下图可以看到，2分13秒之前，吞吐量是呈现稳定增长的趋势，在2分13秒的时候，吞吐量达将近400，2分13秒之后，吞吐量不再是稳定增长的趋势，而是上下幅度，则说明吞吐量达到了极限，所以此请求接口的最大吞吐量在400左右（从图片上看，好像没有到400，只是接近400）
4.7、可以测以下最大吞吐量的情况下，跑一段时间，是否稳定（上面测的400的吞吐量是个大概值，这里稳定跑的话，测350的吞吐量看看），先在200s内稳定增长到350的吞吐量，然后200到500秒的时候，一直持续350s
执行结果如下，稳定跑300s秒没什么问题（不过300秒有点短，真正测试得时候，需要跑长一段时间）：
思考1：为什么达到最大吞吐量之后，吞吐量的值会开始上下波动这么厉害？
个人猜想：比如有一扇门，人从这个们穿过时，最多可10个人同时从此门穿过， 第1秒过一个人，第2秒的时候同时过两个人，第3秒的时候同时过三个人、、、，这样都是可以正常通过的， 当第10的时候同时过十个人还可正常同行，第11秒的时候同时过11个人，但由于最多可同时过10个，但此时11个人同时过门，就出现了拥挤推搡的情况，导致这11个人此门会更加慢一些，当有一个人挤进去了，剩下10个人也就可以快速通行了。因此第12秒过12个人、第13秒过13个人等等情况差不多。所以从第10秒之后，每秒通过门的人数就会有一定的浮动。
思考2：假如 jp@gc-throughput shapping timer 的duriation参数设置的很小，例如让rps 在非常短的时间内，从0增加到300，会怎么样？
后续会执行一下看看，这里先不给结果了。
