概述
我们在用jmeter做性能测试的时候，有一些关键性的性能指标需要去分析。但是由于开源工具本身的局限性，这些指标在工具中的命名极易对我们造成混淆。所以我们需要对这些指标一一进行剖析。
指标分析
响应时间：
假设我们把响应时间分为如下几段：
用户通过客户端向服务端发出请求的时间为： T1
服务端接收到请求，处理该请求的时间为：T2
服务端返回数据给客户端时间为： T3
客户端接收到响应数据，处理数据呈现给用户时间为：T4
从系统视角来看：
系统的响应时间Ts= T1+T2+T3。该时间没有包括客户端对数据处理并呈现的时间T4
从用户视角来看：
用户眼中的的响应时间：Tu = T1+T2+T3+T4。用户通过客户端发出业务请求，到客户端展现相应的请求结果，这个过程的时间越短越好
从服务器视角来看：
服务器接收到客户端发送的请求，并给出响应，这个过程所消耗的时间为响应时间，即服务器仅关注T2
从不同的视角下，衡量响应时间的指标也各不相同。在实际测试过程中，要明确以什么视角验证被测对象的性能。
大多数情况下，我们用jmeter做性能测试的响应时间都以用户视角去看待。
吞吐量：
我们用单位时间内系统处理请求的数量来定义它。吞吐量直接体现了软件系统的业务处理能力
衡量方式如下几种：
请求数 / 单位时间
点击数 / 单位时间
字节数 / 单位时间
jmeter在聚合报告中把吞吐量命名为Throughput
这里要说两个概念，TPS和QPS
TPS：Transactions Per Second（每秒处理的事物数）。一个事务是指向服务器发送请求然后服务器做出反应的过程
QPS：每秒查询率。它是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准
那么我们对于一个页面做一次访问，就会形成一个TPS；但一次页面访问，可能产生多次对服务器的请求，服务器对这些请求，计为“QPS“。
如果访问一个页面会请求服务器3次，那么一次访问产生一个“T”，产生3个“Q”
我们可以用jmeter做一个实验，用一个线程组模拟一个用户去访问一下腾讯新闻首页。那么这一个事物就是一个TPS
观察聚合报告里面的Throughput=7.6/s
它表示这一个线程在一秒内向服务器发送了7.6次请求，此时的Throughput可以理解为QPS。也就是一个TPS产生了7.6个QPS
但是如果我们在这一个请求上挂一个事物控制器，如下所示
此时在聚合报告中，Throughput就不可以和QPS划等号了，而是等同于TPS，它表示我们的系统每秒钟能处理3.4个事物
再比如下图。从登录到退出中间的一系列流程如果都挂在事物控制器下，那么它们整体就可以算做一个事物。TPS就表示每秒钟这一整个流程的处理数量
例：1分钟内系统可以处理1000次考勤打卡事物，则吞吐量TPS=1000/60=16.7 (次/秒)
如下图，则表示系统每秒钟能处理7次请求
并发数（线程数）：
广义
单位时间内同时发送给服务器的请求数，不限定具体业务类型，强调的是同时发送
狭义
是单位时间内同时发送给服务器的相同的业务请求数，需限定具体的业务类型，强调业务请求相同
服务端视角
并发数为单位时间内服务端接收到的请求数
客户端视角
客户端的某个具体业务行为包括多个请求，并发数可被理解为客户端单位时间内同时发送给服务器端的请求数
用户视角
客户端的业务请求一般为用户操作行为，并发数也可理解为并发用户数，又可称为虚拟用户数
未完待续。。。。。。
