我们在用 jmeter 做性能测试的时候，有一些关键性的性能指标需要去分析。但是由于开源工具本身的局限性，这些指标在工具中的命名极易对我们造成混淆。所以我们需要对这些指标逐个进行剖析
用户通过客户端向服务端发出请求的时间为：T1
服务端接收到请求，处理该请求的时间为：T2
服务端返回数据给客户端时间为：T3
客户端接收到响应数据，处理数据呈现给用户时间为：T4
系统的响应时间 Ts= T1+T2+T3
该时间没有包括客户端对数据处理并呈现的时间 T4
用户眼中的的响应时间 Tu = T1+T2+T3+T4
用户通过客户端发出请求到客户端展现请求结果，这个时间越短越好
服务器接收到客户端发送的请求，并给出响应，这个过程所消耗的时间为响应时间，即服务器仅关注 T2
从不同的视角下，衡量响应时间的指标也各不相同。在实际测试过程中，要明确以什么视角验证被测对象的性能。
简称 VU ,指的是系统中操作业务的用户。一般称为虚拟用户数。并发用户数跟注册用户数，在线用户数有很大差别。并发用户数一定会对服务器产生压力，而在线用户数只是挂在系统上，对服务器不产生压力
在已有系统中选取高峰时刻，在一定时间内使用系统的人数，这些人数可认为是在线用户数
数据库中存在的用户数。并发用户数可以取系统用户数的 10%，例如在半个小时内，使用系统的用户数为 10 万，那么取 10%(即 1 万) 作为并发用户数
一般指测试工具为了模拟出用户并发压力而启动的线程，比如 jmeter 里面的 Thread。由于 jmeter 中的线程有迭代的概念，所以通过线程迭代数就可以模拟出用户单位时间最大的并发数。
注意不要把系统并发数和并发用户数* 的概念混在一起哦~
单位时间内同时发送给服务器的请求数，强调同时发送。比如一秒钟点击 100 次查询
单位时间内同时发送给服务器相同的业务，强调业务请求相同。比如一秒钟有 100 人点击了查询按钮
并发数为单位时间内服务端接收到的请求数
单位时间内同时发送给服务端的请求数
客户端的业务请求一般为用户操作行为，也可理解为并发用户数，又可称为虚拟用户数
单位时间内系统处理请求的数量。吞吐量直接体现了软件系统的业务处理能力
Rps 请求数/单位时间
Hps 点击数/单位时间
Tps 通过事物数/单位时间
Qps 查询数/单位时间
随着压力不断增长，实测系统的资源会不断被消耗，TPS 值会因为这些因素而发生变化，并且符合一定的规律
a 点：性能期望值
b 点：高于期望值，系统资源处于临界点
c 点：高于期望值，拐点
d 点：超过最大负载，系统崩溃
从上述模型，将性能测试分为 3 种类型
原点到 a 之间的系统性能，指以系统预期性能指标为前提，对系统不断增加压力，以验证系统能否达到预期性能
a 到 b 的系统性能，是指对系统不断地增加压力或一定压力下的持续运行，直到系统的某项或多项性能指标达到极限，例如某种资源已经达到饱和状态等
b 到 d 之间的系统性能，是指超过安全负载的情况下，对系统不断施加压力，直到系统崩溃，找出系统的瓶颈点和崩溃点。
一个事务是指客户端向服务器发送请求然后服务器做出反应的过程
事物由单个接口请求构成。如一次登录，一次查询
事物由多个接口请求构成。如登录 - 查询 - 新增 - 退出。这四步操作构成一个完整的事物
事务是要靠虚拟用户完成
1 个用户在 1 秒内完成 1 笔事务，那么 TPS 就是 1
1 个事物响应时间是 1ms,那么 1 个用户在 1 秒内能完成 1000 笔事务。TPS 就是 1000
1 笔业务响应时间是 1s,那么 1 个用户在 1 秒内只能完成 1 笔事务。想达到 1000TPS 就至少需要 1000 个用户
因此可以说 1 个用户能产生 1000TPS， 1000 个用户也可以产生 1000TPS，由响应时间决定
并发数=rps* 平均响应时间
RPS 用来描述施压引擎实际发出的压力大小
RPS 模式主要是为了站在服务端视角去直接衡量系统的吞吐能力-TPS 而设计的
并发过低时可能达不到预期的 RPS，并发过高时可能压力过大直接压垮服务器
按照被压测端需要达到的 TPS 去设置相应的 RPS，应用场景主要是一些动态的接口 API，比如登陆、提交订单
金融行业：1000TPS~50000TPS，不包括互联网化的活动
保险行业：100TPS~100000TPS，不包括互联网化的活动
制造行业：10TPS~5000TPS
互联网电子商务：10000TPS~1000000TPS
互联网中型网站：1000TPS~50000TPS
互联网小型网站: 500TPS~10000TPS
