1、获得TPS插件
https://www.cnblogs.com/beginner-boy/p/7806220.html 参见，已保存百度云盘
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，即每秒的响应请求数，也即是最大吞吐能力。
下面我们来共同学习这些参数的作用：
(1)、Lable：Label：每个 JMeter 的 element（例如 HTTP Request）都有一个 Name 属性，这里显示的就是 Name 属性的值；
(2)、#Samples:表示这次测试中一共发出了多少个请求，如果模拟10个用户，每个用户迭代10次，那么这里显示100；【我的是用户有100，只迭代一次，因此也是100】
(3)、Average：平均响应时间——默认情况下是单个 Request 的平均响应时间，当使用了 Transaction Controller 时，也可以以Transaction 为单位显示平均响应时间；
(4)、Median：中位数，也就是 50％ 用户的响应时间；
(5)、90% Line ~ 99% Line：90％ ~99%用户的响应时间；
(6)、Min：最小响应时间；
(7)、Maximum：最大响应时间；
(8)、Error%：本次测试中出现的错误率，即 错误的请求的数量/请求的总数；
(9)、Throughput：吞吐量——默认情况下表示每秒完成的请求数（Request per Second），当使用了 Transaction ；
(10)、Received KB/src：每秒从服务器端接收到的数据量；
(1)1、Sent KB/src：每秒从客户端发送的请求的数量。
有时，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换算 ——很有用的文章 https://blog.csdn.net/taric_ma/article/details/77285522
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个用户并发就足够了。
原文链接：https://blog.csdn.net/u011197146/article/details/83273879