本文主要是介绍Jmeter之性能测试TPS解析，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
1、获得TPS插件
jmeter下TPS插件的安装 - 随风迎 - 博客园 参见，已保存百度云盘
2、添加后，记得使用调度器——每秒50个并发，持续60秒，观察TPS
3、TPS，执行一次事务（包括请求、请求服务器、等待服务器返回等等，比如一个TPS事务，可能触发3个QPS请求）
PS：一秒钟处理的事务数。TPS值越大，一秒钟处理的事务数就越多，说明处理速度越快，软件的效率就越好。
一、TPS：Transactions Per Second（每秒传输的事物处理个数），即服务器每秒处理的事务数。TPS包括一条消息入和一条消息出，加上一次用户数据库访问。（业务TPS = CAPS × 每个呼叫平均TPS）
TPS是软件测试结果的测量单位。一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。客户机在发送请求时开始计时，收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数。
一般的，评价系统性能均以每秒钟完成的技术交易的数量来衡量。系统整体处理能力取决于处理能力最低模块的TPS值。
二、QPS：每秒查询率QPS是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准，在因特网上，作为域名系统服务器的机器的性能经常用每秒查询率来衡量。
对应fetches/sec，即每秒的响应请求数，也即是最大吞吐能力。
有时，Throughput也可以代表吞吐量——如图中，图1中的点在24上下浮动，图2中的Throughput23.7，虽然没有详细计算两个值对比是否一致，但如果单测一个接口时，jmeter聚合报告中的Throughput可以代表吞吐量（也可以手动计算吞吐量=请求数/时间，会发现跟聚合报告中的Throughput几乎相等）
4、吞吐量与并发数
一个接口一秒钟能承受50个并发，不代表可以有50个吞吐量；
吞吐量与系统性能息息相关；
设置长时间跑接口，比如1秒50并发，持续60秒——发现实际接口请求数1461个，时间60秒，TPS参数较稳定；
TPS大概在23左右，所以当前这个接口，系统能处理的事务在23个左右
TPS=请求数/时间
QPS/TPS/并发量/系统吞吐量的概念
QPS: 每秒钟处理完请求的次数；注意这里是处理完。具体是指发出请求到服务器处理完成功返回结果。可以理解在server中有个counter，每处理一个请求加1，1秒后counter=QPS。
TPS：每秒钟处理完的事务次数，一般TPS是对整个系统来讲的。一个应用系统1s能完成多少事务处理，一个事务在分布式处理中，可能会对应多个请求，对于衡量单个接口服务的处理能力，用QPS比较多。
并发量：系统能同时处理的请求数
RT：响应时间，处理一次请求所需要的平均处理时间
计算关系：
QPS = 并发量 / 平均响应时间
并发量 = QPS * 平均响应时间
5、jmeter限制，最多100-200个并发，可以尝试使用LR，LR可监测jvm参数
6、Vu和TPS换算 ——很有用的文章 性能测试知多少 --并发用户数与TPS之间的关系_CN_项目集管理专家(PgMP)的博客-CSDN博客_tps2000支持多少用户同时点击
TPS是每秒事务数，但是事务是要靠虚拟用户做出来的，假如1个虚拟用户在1秒 内完成1笔事务，那么TPS明显就是1；如果某笔业务响应时间是1ms,那么1个用户在1秒内能完成1000笔事务，TPS就是1000了；如果某笔业务 响应时间是1s,那么1个用户在1秒内只能完成1笔事务，要想达到1000TPS，至少需要1000个用户；因此可以说1个用户可以产生 1000TPS，1000个用户也可以产生1000TPS，无非是看响应时间快慢。
7、性能测试策略
做性能测试需要一套标准化流程及测试策略，并发用户数只是指标考虑的一个，在做负载测试的时候，一般都是按照梯度施压的方式去加用户数，而不是在没 有预估的情况下，一次加几万个用户，，交易失败率非常高，响应时间非常长，已经超过了使用者忍受范围内，这样做没有多大的意义，这就好比“有多少钱可以干多少事”一样，需要选择相关的策略。
8、总结
- 系统的性能由TPS决定，跟并发用户数没有多大关系。在同样的TPS下，可以由不同的用户数去压（通过加思考时间设置）。
- 系统的最大TPS是一定的（在一个范围内），但并发用户数不一定，可以调整。
- 建议性能测试的时候，不要设置过长的思考时间，以最坏的情况下对服务器施压。
- 一般情况下，大型系统（业务量大、机器多）做压力测试，5000个用户并发就够了，中小型系统做压力测试，1000个用户并发就足够了。
9、应用场景
1⃣️比如要单独测试一个用户注册接口，想知道在配置A情况下tps是多少：设置请求时间如300s（短时间一般很难压出来，可以设置5-10分钟对比看下），同样配置下（机器、带宽等），改变线程数，并发数50-100-150，以此类推，可以观察jmeter查看结果树中的Throughput，通常会得出峰值曲线，也就是在某个并发范围内，tps达到最高值，低于或高于该线程数范围，tps会下降。那么，可以得出该接口最高tps值是多少（在xx并发数情况下、配置情况下）
2⃣️可以对比不同环境配置（机器、带宽等等）或代码优化后，同样线程请求下，tps最高值对比
——打个比方，可以理解接口类似于一个安全出口，tps类似于同一时间下通过人数，线程数为通过人数；当通过人数仅有10，安全出口不拥挤，一个个慢慢走过，tps是低的；当通过人数比如100，安全出口正好可以全部通过，此时tps达到峰值；当通过人数远远大于安全出口容量，如1000，此时爆挤，每个人都想通过，安全出口本来可以出100人，但是因为拥挤只能走30人；最坏情况10000人或者更高，那么这种情况下如果是豆腐渣工程，安全出口就挤崩了（类似于高并发情况下请求无响应）。所以需要测试不同线程数、时间情况下 tps最高是多少。
该种情况下是为了得到接口真实tps（比如内部对接口性能要求等），并不是通常用户或客户理解的‘你们能承受多少并发’，实际场景中接口的用户并发数多高，需要参考 吞吐量定时器来设置，以及根据接口应用场景设计性能场景。
这篇关于Jmeter之性能测试TPS解析的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
