性能测试(二)-重要性能指标TPS、RT

通常有两个层面的问题，如“一个系统在多少响应之下能支持多少TPS？”、“业务状态是什么，如果1000万人在线会不会有问题？”
那么这正是性能需求指标中的技术指标和业务指标。
技术指标和业务指标之前的关系，请看以下示意图：

所有的技术指标都是有业务场景的前提下制定的，而技术指标和业务指标之前也要有详细的换算过程。这样，在回答了技术指标是否满足的同时，也能回答是否可以满足业务指标。
目前常用的性能指标表示法有：

先说一下最常用的TPS，TPS是性能领域中一个关键的性能指标概念，用来描述每秒事务数。TPS在不同行业不同业务中定义的粒度都是不同的。所以不管在哪里用TPS，一定要有个前提，就是所有相关的人都要知道你的T是如何定义的。
通常情况下，我们回根据场景的目的来定义TPS的粒度。如果是接口层性能测试，T可以定义为接口级；如果是业务级性能测试，T可以定义为每个业务和完整的业务流。所以，性能中TPS中的T的定义取决于场景的目标和T的作用。当和同事在沟通性能指标用哪些概念是，应该描述的更具体一些，说某个概念是，最好加上相应的背景条件。
在性能中，还有一个重要概念就是响应时间RT(Response Time)，响应时间是从提交请求到返回结果的时间。对于响应时间来说，时间的拆分定位是性能瓶颈分析中非常重要的一节。

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

很多人认为线程好像是真实的用户一样，并发的线程多少就描述出了多少真实的用户。但事实上，并发线程数在没有模拟真实用户操作的情况下，和真实的用户操作差别非常远。

在压力工具中，如果有4个并发线程，每个线程都可以在1秒内完成4个事务，那么总的TPS应该是16。
另外，并发是需要具体的指标来承载的，你可以说，我的并发是1000TPS，或1000RPS，或1000HPS。
用户数怎么来定义呢？有些人认为一个系统如果有一万人在线，那就应该测试一万的并发线程，其实不然。通常，我们会对在线的用户做并发度的分析，在很多业务中，并发度都会低于5%，甚至低于1%。
拿5%来计算，就是10000用户×5%=500TPS(注意这里是TPS，不是并发线程数)。如果这时的响应时间是100ms，那并发线程数是500TPS/(1000ms/100ms)=50并发线程。用户数、线程数和TPS之前的关系如下：

当然，响应时间不会是固定的100ms，上面的这个比例会随着并发线程数的增加出现趋势上的关系。