从业务和技术的不同角度，对性能指标的定义是不同的，所以性能指标可以分为技术指标和业务指标。技术指标建立在具体的业务场景中，技术指标和业务指标之间要进行换算。以下图来说明技术指标和业务指标的关系。
常见性能指标：
响应时间 RT
Response Time。可以简单理解为：网络传输（请求）时间+服务器处理（一层或多层）时间+网络传输（响应）时间
从一个实例中理解：
RT = T2 – T1 。计算方式似乎容易，但是响应时间的定位就比较复杂了。因为性能测试工具都会记录响应时间，但是，都不会给出后端链路到底哪里慢。
从这个简单架构图来看请求链路：
在所有服务的进出口都做记录，然后计算结果，在网关、总线这样的系统都会考虑这个功能。现在的一些链路监控工具和一些 Metrics 的使用可以完成需求，他会记录每一个请求链路上每个节点消耗时间和请求的持续时间。
每秒事务数量 TPS
Transations Per Second。而这个 TPS 中的 T 需要有一个明确理解
通常情况下，我们会根据场景的目的来定义 TPS 的粒度。如果是接口层性能测试，T 可以
直接定义为接口级；如果业务级性能测试，T 可以直接定义为每个业务步骤和完整的业务
流。
用图示简单说明下：
如果我们要单独测试接口 1、2、3，那 T 就是接口级的；如果我们要从用户的角度来下一
个订单，那 1、2、3 应该在一个 T 中，这就是业务级的了
当然，这时还要分析系统是如何设计的。通常情况下，积分都会异步，而库存不能异步。所以这个业务，可以看成只有 1、2 两个接口，但是在做这样的业务级压力时，3 接口也是必须要监控分析的。
所以，性能中 TPS 中 T 的定义取决于场景的目标和 T 的作用。可以这样来定事务
要创建什么级别的事务，完全取决于测试的目的。一般可以从上到下的顺序一一地来测试，这样路径清晰地执行是容易定位问题
搞清楚了 TPS 的 T 是什么，那其实 TPS 就是字面意思：每秒事务数。在性能测试过程中，TPS 之所以重要，是因为它可以反应出一个系统的处理能力。
每秒查询数 QPS
它描述的是数据库中的 Query Per Second，从上面的示意图中来看，其实描述的是服务后面接的数据库中 SQL 的每秒执行条数。如果描述的是前端的每秒查询数，那就不包括插入、更新、删除操作了。显然这样的指标用来描述系统整体的性能是不够全面的。所以不建议用 QPS 来描述系统整体的性能，以免产生误解
每秒请求数 QPS
Request per second，每秒请求数。对于请求数来说，要看是在哪个层面看到的请求，因为请求这个词，实在是太泛了。我们把上面的图做一点点变化来描述一下请求数
如果一个用户点击了一次，发出来 3 个 HTTP Request，调用了 2 次订单服务，调用了 2
次库存服务，调用了 1 次积分服务，那么这个 Request 该如何计算？
在具体的项目中，我们会单独描述每个服务，以便做性能统计。如果要描述整体，最多算是有 3 个 RPS。如果从 HTTP 协议的角度去理解，那么 HTTP Request 算是一个比较准确的描述了，但它本身的定义并没有包含业务。如果赋予它业务的含义，那么用它来描述性能也是可以的
吞吐量
吞吐量是指系统在单位时间内处理请求的数量，用于衡量网络性能或软件性能,TPS、QPS都是吞吐量的常用量化指标。
一个系统的吞吐量（承压能力）与request（请求）对cpu的消耗，外部接口，IO等等紧密关联。
单个request 对cpu消耗越高，外部系统接口，IO影响速度越慢，系统吞吐能力越低，反之越高。
每秒点击数 HPS
Hits Per Second，每秒点击数。Hit 一般在性能测试中，都用来描述 HTTP Request。但是，也有一些人用它描述真正的客户在界面上的点击次数。关于这一点，就只有在具体的项目中才能规定得具体一些。当它描述 HTTP Request 时，如果 RPS 也在描述HTTP Request，那这两个概念就完全一样了
每秒 / 每分钟调用次数 CPS/CPM
Calls Per Second/ Calls Per Minutes 。这个描述在接口级是经常用到的，比如说上面的订单服务。显然一次客户界面上的点击调用两次。这个比较容易理解。但是，在操作系统级，我们也经常会听到系统调用用 call 来形容，比如说用 strace 时，你就会看见 Calls 这样的列名。
这些概念本身并没有问题，但是当上面的概念都用来描述一个系统的性能能力的时候，就混
乱了。对于这种情况，我觉得有几种处理方式：
- 用一个概念统一起来。我觉得直接用 TPS 就行了，其他的都在各层面加上限制条件来描
述。比如说，接口调用 1000 Calls/s，这样不会引起混淆。 - 在团队中定义清楚术语的使用层级。
- 如果没有定义使用层级，那只能在说某个概念的时候，加上相应的背景条件。
压力工具中的线程数和用户数与 TPS
下面的一个框有四个箭头，每个都代表相同的事务。
在说这个图之前，我们要先说明”并发“这个概念。他是需要具体的指标来承载的。你可以说，我的并发是 1000TPS，或者 1000RPS，或者 1000HPS，这都随便去定义。但是在一个具体的项目中，当说到并发 1000 这样没有单位的词时，需要让大家都能理解这是什么。
在上面这张示意图中，其实压力工具是 4 个并发线程，由于每个线程都可以在一秒内完成4 个事务，所以总的 TPS 是 16。不能把并发理解成 4 了。
那么用户数怎么来定义呢？用户有了业务含义，不能认为一个系统如果有 1 万个用户在线，那就应该测试 1 万的并发线程。通常，我们会对在线的用户做并发度的分析，在很多业务中，并发度都会低于5%，甚至低于 1%。
拿 5% 来计算，就是 10000 用户 x5%=500(TPS)，注意哦，这里是 TPS，而不是并发线程数。如果这时响应时间是 100ms，那显然并发线程数是 500TPS/(1000ms/100ms)=50(并发线程)。
通过这样的计算逻辑，我们就可以看出来用户数、线程数和 TPS 之间的关系了
但是！响应时间肯定不会一直都是 100ms 。所以通常情况下，上面的这个比例都不会固定，而是随着并发线程数的增加，会出现趋势上的关系。