一  QPS、TPS基本性能指标

QPS：Queries Per Second意思是“每秒查询率”，是一台服务器每秒能够相应的查询次数，是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。

TPS：是Transactions Per Second的缩写，也就是事务数/秒。吞指系统在单位时间内处理请求的数量。

我们会根据场景的目的来定义 TPS 的粒度。如果是接口层性能测试，T 可以直接定义为接口级；如果业务级性能测试，T 可以直接定义为每个业务步骤和完整的业务流。

所以，性能中 TPS 中 T 的定义取决于场景的目标和 T 的作用。一般我们都会这样来定事务。

接口级脚本：

——事务 start（接口 1）接口 1 脚本

——事务 end（接口 1）

——事务 start（接口 2）接口 2 脚本

——事务 end（接口 2）

——事务 start（接口 3）接口 3 脚本

——事务 end（接口 3）

业务级接口层脚本（就是用接口拼接出一个完整的业务流）：

——事务 start（业务 A）

接口 1 脚本 - 接口 2（同步调用）

接口 1 脚本 - 接口 3（异步调用）

——事务 end（业务 A）用户级脚本

——事务 start（业务 A）

点击 0 - 接口 1 脚本 - 接口 2（同步调用）

点击 0 - 接口 1 脚本 - 接口 3（异步调用）

——事务 end（业务 A）

你要创建什么级别的事务，完全取决于测试的目的是什么。

性能测试的其他指标

---

二  压力工具中的并发数，用户数和TPS

并发数：

在上面这张示意图中，其实压力工具是 4 个并发线程，由于每个线程都可以在一秒内完成 4 个事务，所以总的 TPS 是 16。这非常容易理解吧。而在大部分非技术人的脑子里，这样的场景就是并发数是 4，而不是 16。

用户数：

涉及到用户就会比较麻烦一点。因为用户有了业务含义，所以有些人认为一个系统如果有 1 万个用户在线，那就应该测试 1 万的并发线程，这种逻辑实在是不技术。通常，我们会对在线的用户做并发度的分析，在很多业务中，并发度都会低于 5%，甚至低于 1%。

拿 5% 来计算，就是 10000 用户 x5%=500(TPS)，注意哦，这里是 TPS，而不是并发线程数。如果这时响应时间是 100ms，那显然并发线程数是 500TPS/(1000ms/100ms)=50(并发线程)。（对一个线程来说，如果响应时间是100ms，那这个线程在一秒内不就是：1000ms/100ms = 10tps了吗？如果要达到500TPS，那需要多少线程呢？就是500TPS/10TPS=50线程。）

---

三  性能测试概念一些错误的观念

 1.二八原则

28 原则来计算并发用户数。大概的意思就是，如果一天有 1000 万的用户在使用，系统如果开 10 个小时的话，在计算并发用户数的时候，就用 2 小时来计算，即 1000 万用户在 2 小时内完成业务。

业务模型应该如何得到呢？

这里有两种方式是比较合理的：

（1）根据生产环境的统计信息做业务比例的统计，然后设定到压力工具中。有很多不能在线上直接做压力测试的系统，都通过这种方式获取业务模型。

（2）直接在生产环境中做流量复制的方式或压力工具直接对生产环境发起压力的方式做压力测试。这种方式被很多人称为全链路压测。其实在生产中做压力测试的方式，最重要的工作不是技术，而是组织协调能力。相信参与过的人都能体会这句话的重量。

 2.响应时间的 258 原则

其实这是在 80 年代的时候，英国一家 IT 媒体对音乐缓冲服务做的一次调查。在那个年代，得到的结果是，2 秒客户满意度不错；5 秒满意度就下降了，但还有利润；8 秒时，就没有利润了。于是他们就把这个统计数据公布了出来，这样就出现了 258 principle，翻译成中文之后，它就像一个万年不变的定理，深深影响着很多人。

那么响应时间如何设计比较合理呢？这里有两种思路推荐给你。

(1) 同行业的对比数据。

(2)找到使用系统的样本用户（越多越好），对他们做统计，将结果拿出来，就是最有效的响应时间的制定标准。

---

四  总结

性能测试概念中：性能指标、性能模型、性能场景、性能监控、性能实施、性能报告。

性能场景中：基准场景、容量场景、稳定性场景、异常场景。

性能指标中：TPS、RT。 （记住 T 的定义是根据不同的目标来的）

有了这些之后，一个清晰的性能框架就已经出现了。

性能测试模型 性能测试场景

从业务指标和技术指标来定义性能需求指标。所有的技术指标都是在有业务场景的前提下制定的，而技术指标和业务指标之间也要有详细的换算过程

业务指标和技术指标