jmeter性能测试，各个指标的预估/测试出来/计算出来，各种关系

性能测试调试时使用：
性能测试指标评估，需要满足用户量计算（2/8原则）：
例如: 业务量10000 ，持续时间为1min ，接口平均响应时间为0.4S ，调度时间300s
基本估算：
1.吞吐量是可以提前估算的，吞吐量(QPS)=(1000080%) / (16020%)=667；
照着吞吐量去预估QPS，但实际测试后能能拿到真正的QPS= 请求总个数 除以 测试执行持续总时间，则N台机器，总qps=单台qps乘以N。再明确下各种指标的关系：
吞吐量是指系统在单位时间内处理请求的数量，一般采用2/8原则计算，TPS、QPS都是吞吐量的常用量化指标，QPS/TPS(衡量系统处理能力的重要指标)。
一个系统吞吐量通常有QPS(TPS) 和 并发数 两个因素决定，每套系统这个两个值都有一个相对极限值，在应用场景访问压力下，只要某一项达到系统最高值，系统吞吐量就上不去了，如果压力继续增大，系统的吞吐量反而会下降，原因是系统超负荷工作，上下文切换，内存等等其他消耗导致系统性能下降。
日吞吐量：
压力測试出TPS为100，那么系统的日吞吐量=10011*3600=396万
这个是在简单（单一url）的情况下。有些页面。一个页面有多个request，系统的实际吞吐量还要小。

QPS
Queries Per Second 是每秒查询率 ,是一台服务器每秒能够相应的查询次数，是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准, 即每秒的响应请求数，也即是最大吞吐能力。
TPS
TPS Transactions Per Second 也就是事务数/秒。一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。客户机在发送请求时开始计时，收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数。

TPS即每秒处理事务数，包括了
–用户请求服务器
–服务器自己的内部处理
–服务器返回给用户
这三个过程，每秒能够完成N个这三个过程，Tps也就是N；

QPS基本类似于TPS，但是不同的是，对于一个页面的一次访问，形成一个Tps；但一次页面请求，可能产生多次对服务器的请求，服务器对这些请求，就可计入“Qps”之中。

例子：
访问一个页面会请求服务器3次，一次返回，那就是会产生一个“T”，产生3个“Q”；
再举例，一个大胃王一秒能吃10个包子，一个女孩子0.1秒能吃1个包子，那么他们是不是一样的呢？答案是否定的，因为这个女孩子不可能在一秒钟吃下10个包子，她可能要吃很久。这个时候这个大胃王就相当于TPS，而这个女孩子则是QPS。虽然很相似，但其实是不同的。

2.一般认为并发数=线程数（不循环），实际上真正的并发数= QPS 乘以 平均响应时间=667*0.4=266，并发数可以计算出来；并发数越大越好？不是！平均响应时间需要正常的时候，算出来的并发数才准确，如果平均响应时间10s，先解决平均响应时间过长的问题；总并发数=单台并发数乘以N；并发数：系统同时处理的request/事务数，并发数（并发度）：指系统同时能处理的请求数量，同样反应了系统的负载能力。QPS(TPS)=并发数/平均响应时间，也就是说：
并发数= QPS 乘以 平均响应时间
响应时间：响应时间是指从客户端发一个请求开始计时，到客户端接收到从服务器端返回的响应结果结束所经历的时间，响应时间由请求发送时间、网络传输时间和服务器处理时间三部分组成。一般取平均响应时间

明确jmeter的线程数，有没有限制呢？
jmeter本身是没有对线程数做限制的。但是jmeter启动这些并发用户数时，需要消耗资源，受电脑cpu的主频限制，一台电脑不可能创建无限量的线程数。
实际的情况，「http协议」的脚本，一台电脑的线程数大概能产生1500左右并发用户数，可能产生2000个并发用户数，但是可能会出错，肯定能产生1000个并发用户数左右。
也就是说，1台电脑，「http协议」脚本，保守估计是可以产生1000个并发用户数。
如果你想模拟超过1000并发用户数，你可能需要考虑「分布式（用多台电脑）」。
其它的协议和受一些别的因素的影响，产生的并发用户数量也不同。

调试方法：
通过调整线程数/启动所有线程的时间/执行时间，以调整线程数为主，进行qps，平均响应时间，最大并发数的寻找；
注意事项：批量接口还需要注意参数个数，需要等价类验证；

最重要的三个指标：
QPS-----能测出来
平均响应时间------能测出来
并发数 = QPS*平均响应时间