如何理解TPS、QPS、RT、吞吐量这些性能指标

性能测试行业常用的性能指标表示法

压力工具中的线程数和用户数与 TPS

多人都没有明白压力工具中的线程数和用户以及 TPS 之间是怎样的关系。同样，我们先画一个示意图来说明一下。

这里先说明一个前提，上面的一个框中有四个箭头，每个都代表着相同的事务。在说这个图之前，我们要先说明“并发”这个概念是靠什么数据来承载的。在上面的内容中，我们说了好多的指标，但并发是需要具体的指标来承载的。你可以说，我的并发是 1000TPS，或者 1000RPS，或者 1000HPS，这都随便你去定义。但是在一个具体的项目中，当你说到并发 1000 这样没有单位的词时，一定要让大家都能理解这是什么。在上面这张示意图中，其实压力工具是 4 个并发线程，由于每个线程都可以在一秒内完成 4 个事务，所以总的 TPS 是 16。这非常容易理解吧。而在大部分非技术人的脑子里，这样的场景就是并发数是 4，而不是 16。要想解释清楚这个非常困难，我的做法就是，直接告诉别人并发是 16 就好了，不用关心 4 个线程这件事。这在我所有项目中几乎都是一样的，一直也没有什么误解。

户数、线程数和 TPS 之间的关系

那么用户数怎么来定义呢？涉及到用户就会比较麻烦一点。因为用户有了业务含义，所以有些人认为一个系统如果有 1 万个用户在线，那就应该测试 1 万的并发线程，这种逻辑实在是不技术。通常，我们会对在线的用户做并发度的分析，在很多业务中，并发度都会低于 5%，甚至低于 1%。拿 5% 来计算，就是 10000 用户 x5%=500(TPS)，注意哦，这里是 TPS，而不是并发线程数。如果这时响应时间是 100ms，那显然并发线程数是 500TPS/(1000ms/100ms)=50(并发线程）【每秒500个事务X0.1秒=0.1秒内的用户数】}。通过这样简单的计算逻辑，我们就可以看出来用户数、线程数和 TPS 之间的关系了

如果这时响应时间是 100ms，那显然并发线程数是 500TPS/(1000ms/100ms)=50(并发线程)。

解答：

对一个事务来说，如果响应时间是100ms，那这个在一秒内事务数不就是：1000ms/100ms = 10tps了吗？
如果要达到500TPS，那需要多少线程呢？就是500TPS/10TPS=50线程。

也可以这样理解：

500tps*(100ms/1000ms),100ms转换成0.1秒，500tps=每秒500个事务数 0.1秒=50个事务

但是！响应时间肯定不会一直都是 100ms 的嘛。所以通常情况下，上面的这个比例都不会固定，而是随着并发线程数的增加，会出现趋势上的关系。所以，在性能分析中，我一直在强调着一个词：趋势！

响应时间的 258 原则合理吗？

对于响应时间，有很多人还在说着 258 或 2510 响应时间是业内的通用标准。然后我问他们这个标准的出处在哪里？谁写的？背景是什么？几乎没有人知道。真是不能想像，一个谁都不知道出处的原则居然会有那么大的传播范围，就像谣言一样，出来之后，再也找不到源头。其实这是在 80 年代的时候，英国一家 IT 媒体对音乐缓冲服务做的一次调查。在那个年代，得到的结果是，2 秒客户满意度不错；5 秒满意度就下降了，但还有利润；8 秒时，就没有利润了。于是他们就把这个统计数据公布了出来，这样就出现了 258 principle，翻译成中文之后，它就像一个万年不变的定理，深深影响着很多人。距离这个统计结果的出现，已经过去快 40 年了，IT 发展的都能上天了，这个时间现在已经完全不适用了。所以，以后出去别再提 258/2510 响应时间原则这样的话了，太不专业。那么响应时间如何设计比较合理呢？这里有两种思路推荐给你。同行业的对比数据。找到使用系统的样本用户（越多越好），对他们做统计，将结果拿出来，就是最有效的响应时间的制定标准。

总结:

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

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

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