性能指标：TPS、QPS、并发数、RT概念详解

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

响应时间(RT) 

响应时间是指系统对请求作出响应的时间。直观上看，这个指标与人对软件性能的主观感受是非常一致的，因为它完整地记录了整个计算机系统处理请求的时间。由于一个系统通常会提供许多功能，而不同功能的处理逻辑也千差万别，因而不同功能的响应时间也不尽相同，甚至同一功能在不同输入数据的情况下响应时间也不相同。所以，在讨论一个系统的响应时间时，人们通常是指该系统所有功能的平均时间或者所有功能的最大响应时间。当然，往往也需要对每个或每组功能讨论其平均响应时间和最大响应时间。 

对于单机的没有并发操作的应用系统而言，人们普遍认为响应时间是一个合理且准确的性能指标。需要指出的是，响应时间的绝对值并不能直接反映软件的性能的高低，软件性能的高低实际上取决于用户对该响应时间的接受程度。对于一个游戏软件来说，响应时间小于100毫秒应该是不错的，响应时间在1秒左右可能属于勉强可以接受，如果响应时间达到3秒就完全难以接受了。而对于编译系统来说，完整编译一个较大规模软件的源代码可能需要几十分钟甚至更长时间，但这些响应时间对于用户来说都是可以接受的。 

吞吐量(TPS) 

TPS，这是一项关键指标，用来描述「每秒事务数」，可以反应出一个系统的处理能力。

但是，TPS 在不同的行业、不同的业务中定义的粒度都是不同的。所以不管你在哪里用 TPS，一定要有一个前提，「就是所有相关的人都要知道你的 T 是如何定义的」。

如图所示，一个业务流程图：

• 如果要单独测试接口 1、2、3，那么 T 就是接口级的。
• 如果我们要从用户的角度来下一个订单，那 1、2、3 应该在一个 T 中，这就是业务级的了。

当然了，「还要具体看系统是怎么设计的」。通常来说，积分服务是异步的，而库存不是异步，那么这个业务级就可以看做是 1、2 两个接口。但是，在做这样的业务级压力时，3 接口也是必须要监控分析的。

「所以，性能中 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）

结合上述示例，再次理解下：「你要创建什么级别的事务，完全取决于测试的目的是什么」，这句话。

另外，在测试过程中，通常是「先接口级、后业务级」的顺序，容易定位问题。

并发用户数 

并发用户数是指系统可以同时承载的正常使用系统功能的用户的数量。与吞吐量相比，并发用户数是一个更直观但也更笼统的性能指标。实际上，并发用户数是一个非常不准确的指标，因为用户不同的使用模式会导致不同用户在单位时间发出不同数量的请求。一网站系统为例，假设用户只有注册后才能使用，但注册用户并不是每时每刻都在使用该网站，因此具体一个时刻只有部分注册用户同时在线，在线用户就在浏览网站时会花很多时间阅读网站上的信息，因而具体一个时刻只有部分在线用户同时向系统发出请求。

这样，对于网站系统我们会有三个关于用户数的统计数字：注册用户数、在线用户数和同时发请求用户数。由于注册用户可能长时间不登陆网站，使用注册用户数作为性能指标会造成很大的误差。而在线用户数和同事发请求用户数都可以作为性能指标。相比而言，以在线用户作为性能指标更直观些，而以同时发请求用户数作为性能指标更准确些。 

每秒查询率(QPS) 

QPS 一开始是用来描述 MySQL 中 SQL 每秒执行数 Query Per Second，所有的 SQL 都被称为 Query。后来，由于一些文章的转来转去，QPS 被慢慢地移到了压力工具中，用来描述吞吐量。

如果描述的是前端的每秒查询数，那就不包括插入、更新、删除操作了。显然这样的指标用来描述系统整体的性能是「不够全面」的，所以不建议用 QPS 来描述系统整体的性能。