没有说啥内容啊，好像就是把成果说了一下

JMeter 中无法通过现有组件排列组合实现这种效果，因为他是阻塞执行的，必须执行完一个请求才会执行下一个请求，不过可以迂回一下，使用同一个线程组或者不同线程组的参数 + 时间来实现这种效果。比如使用一个线程间的共享变量，让一个线程通过一个 while 循环进入第二个个 while 循环， 让第二个线程放入第一个 while 循环中，让他们在各组的循环中等待某个时间到了之后执行请求。

刚看了下思路完全不一样，大佬做的比较全，连 Web 页面都提供了，我这个要手动执行 JAVA 程序，而且可以说思路完全不一样

嗯嗯

Groovy 中 getClass 不可用 ?

值得反思。招人的时候，短短一个小时，一个人业务测试做的怎么样，是否认真，很难看出来。但是一个人的技术怎么样，通过几个技术问题却是能很快了解。慢慢的让许多人对技术侧的倚重越来越强。对业务测试工作忽略。

需要在 module_config 表中增加一条记录，其中 app_name = repeater ，environment = daily，因为 bootstarap.sh 中的启动代码是 -Dapp.name=repeater \ -Dapp.env=daily \ 要保持一致，不然数据库中查出为空还会报空指针异常。

首先我对 TPS、QPS、RPS 这些概念认为都查不多，只是细微之处有些变化来描述一种特定的场景，没必要纠结那个大于哪个，反正都是反映服务器的性能，对于性能测试工具 JMeter 是 BIO 的，也就是同步阻塞，这样做有及其大的优势，同时更加符合人的操作逻辑。不然一整套逻辑接口，后面的接口的数据怎样根据前面已知的条件生成？（之后输入的数据根据已知的条件随机生成才能更加符合人的操作逻辑），数据也能更好的监控。JMeter 的分布式压测产生的背景是一台客户端由于内存、CPU 、网络（主要是内存）的限制造不成更加的压力，因为 JMeter 是基于线程的内存开销较大。
对单个接口来说多线程访问因为代码逻辑是一样的，在不考虑线程占用内存的影响时，TPS 最大值应该是一个固定的值，但是创建一个线程会占用服务器的内存资源，从这方面说 高线程就是等于高压力，基于线程也是 JMeter 的一种局限，因为单台客户端产生的线程有限，所以才有了分布式解决这个问题。
线程会占用服务器内存和 CPU 资源，同时也挤占了程序运行时的资源，所以高并发（大量线程）会造成内存溢出。也会造成 TPS 下降，楼主的那种情况应该是虚拟用户数过低，也就是服务器中运行的线程数不足以把程序运行的空间挤压的很小，造成程序处理速度变慢，又回到上面说的当 JMeter 一个线程发送一个请求没有响应的时候该线程是不会再发送第二个请求的。所以要想出现性能拐点必须增加虚拟用户数量，一方面需要单个客户端增大线程数量，另一方面分布式多个客户端运行。就好了。
最后说说，任何工具都有优点和局限性，有的特性可能在某种角度先是优点从另一种角度看就是局限性。JMeter 作为性能测试工具很好用。

不会影响被测试程序，无论怎么查询只是查询 InfluxDB，对 InfluxDB 所在的服务器造成点压力，跟被测对象程序没关系