本文主要是介绍经验分享：JMeter控制RPS，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
一、前言
RPS (Request Per Second)一般用来衡量服务端的吞吐量，相比于并发模式，更适合用来摸底服务端的性能。我们可以通过使用 JMeter 的常数吞吐量定时器来限制每个线程的RPS。对于RPS，我们可以把他理解为我们的TPS，我们就不过多解释了。
RPS 取决于压测的并发数以及服务的响应时间，并发数过高，可能压力过大压垮后端服务，并发数过低，可能压不到指定的 RPS。为了避免压力过大压垮后端服务以及摸底后端服务性能上限，可以通过设置常数吞吐量定时器来限制线程的 RPS 上限。接下来我们用很短的篇幅来简单说下如何控制脚本的RPS
二、配置RPS
常数吞吐量定时器的设置十分的简单，这里我们设置的RPS就是21000/60=350RPS。
第二个基于计算吞吐量字段，字面意思也很清晰了
只有此线程：控制每个线程的吞吐量，总的吞吐量为设置的目标吞吐量乘以该线程的数量
所有活动线程：设置的目标吞吐量将分配在每个活跃线程上，每个活跃线程在上一次运行结束后等待合理的时间后再次运行。活跃线程指同一时刻同时运行的线程。
所有活动线程(共享)：与所有活动线程的选项基本相同。唯一区别是，每个活跃线程都会在所有活跃线程上一次运行结束后等待合理的时间后再次运行。
当前线程组中的所有活动线程：设置的目标吞吐量将分配在当前线程组的每一个活跃线程上，当测试计划中只有一个线程组时，该选项和所有活动线程选项的效果完全相同。
当前线程组中的所有活动线程(共享)：与当前线程组中的所有活动线程基本相同，唯一的区别是，每个活跃线程都会在所有活跃线程的上一次运行结束后等待合理的时间后再次运行。
三、运行结果
很明显，运行结果中RPS最高为350左右
以上就是这节的全部内容，如有错误，还请各位指正!
总结：
感谢每一个认真阅读我文章的人！！！
作为一位过来人也是希望大家少走一些弯路，如果你不想再体验一次学习时找不到资料，没人解答问题，坚持几天便放弃的感受的话，在这里我给大家分享一些自动化测试的学习资源，希望能给你前进的路上带来帮助。
软件测试面试文档
我们学习必然是为了找到高薪的工作，下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料，并且有字节大佬给出了权威的解答，刷完这一套面试资料相信大家都能找到满意的工作。
视频文档获取方式：
这份文档和视频资料，对于想从事【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴我走过了最艰难的路程，希望也能帮助到你！以上均可以分享，点下方小卡片即可自行领取。
这篇关于经验分享：JMeter控制RPS的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
