目录
在上一篇文章中，我们讲述了性能场景，下面就要说性能需求指标了。
通常我们都从两个层面定义性能场景的需求指标：业务指标和技术指标。
这两个层面需要有映射关系，技术指标不能脱离业务指标。一旦脱离，你会发现你能回答“一个系统在多少响应时间之下能支持多少 TPS”这样的问题，但是回答不了“业务状态是什么”的问题。
举例来说，如果一个系统要支持 1000 万人在线，可能你能测试出来的结果是系统能支持 1 万 TPS，可是如果问你，1000 万人在线会不会有问题？这估计就很难回答了。
我在这里画一张示意图以便你理解业务指标和性能指标之间的关系。
这个示意显然不够详细，但也能说明关系了。所有的技术指标都是在有业务场景的前提下制定的，而技术指标和业务指标之间也要有详细的换算过程。这样一来，技术指标就不会是一块飞地。同时，在回答了技术指标是否满足的同时，也能回答是否可以满足业务指标。
有了这样的关联关系，下面我们看一下性能测试行业常用的性能指标表示法。
我将现在网上能看到的性能指标做了罗列，其中不包括资源的指标。因为资源类的比较具体，并且理解误差并不大，但业务类的差别就比较大了。
对这些性能指标都有哪些误解
我记得我还年轻的时候，还没有 QPS、RPS、CPS 这样的概念，只有 TPS。那个时候，天总是那么蓝，时间总是那么慢，“你锁了人家就懂了”。
QPS 一开始是用来描述 MySQL 中 SQL 每秒执行数 Query Per Second，所有的 SQL 都被称为 Query。后来，由于一些文章的转来转去，QPS 被慢慢地移到了压力工具中，用来描述吞吐量，于是这里就有些误解，QPS 和 TPS 到底是什么关系呢？
RPS 指的是每秒请求数。这个概念字面意思倒是容易理解，但是有个容易误解的地方就是，它指的到底是哪个层面的 Request？如果说 HTTP Request，那么和 Hits Per Second 又有什么关系呢？
HPS，这也是个在字面意思上容易理解的概念。只是 Hit 是什么？有人将它和 HTTP Request 等价，有人将它和用户点击次数等价。
CPS，用的人倒是比较少，在性能行业中引起的误解范围并不大。同时还有喜欢用 CPM（Calls Per Minute，每分钟调用数）的。这两个指标通常用来描述 Service 层的单位时间内的被其他服务调用的次数，这也是为什么在性能行业中误解不大的原因，因为性能测试的人看 Service 层东西的次数并不多。
为了区分这些概念，我们先说一下 TPS（Transactions Per Second）。我们都知道 TPS 是性能领域中一个关键的性能指标概念，它用来描述每秒事务数。我们也知道 TPS 在不同的行业、不同的业务中定义的粒度都是不同的。所以不管你在哪里用 TPS，一定要有一个前提，就是所有相关的人都要知道你的 T 是如何定义的。
经常有人问，TPS 应该如何定义？这个实在是没有具体的“法律规定”，那就意味着，你想怎么定就怎么定。
通常情况下，我们会根据场景的目的来定义 TPS 的粒度。如果是接口层性能测试，T 可以直接定义为接口级；如果业务级性能测试，T 可以直接定义为每个业务步骤和完整的业务流。
我们用一个示意图来说明一下。
如果我们要单独测试接口 1、2、3，那 T 就是接口级的；如果我们要从用户的角度来下一个订单，那 1、2、3 应该在一个 T 中，这就是业务级的了。
当然，这时我们还要分析系统是如何设计的。通常情况下，积分我们都会异步，而库存不能异步哇。所以这个业务，你可以看成只有 1、2 两个接口，但是在做这样的业务级压力时，3 接口也是必须要监控分析的。
所以，性能中 TPS 中 T 的定义取决于场景的目标和 T 的作用。一般我们都会这样来定事务。
1、接口级脚本：
——事务 start（接口 1）
接口 1 脚本
——事务 end（接口 1）
——事务 start（接口 2）
接口 2 脚本
——事务 end（接口 2）
——事务 start（接口 3）
接口 3 脚本
——事务 end（接口 3）
最低0.47元/天 解锁文章
174
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
