性能测试基础

一、性能测试概念

• 性能测试针对系统的性能指标，建立性能测试模型，制定性能测试方案，制定监控策略，在场景条件之下执行性能场景，分析判断性能瓶颈并调优，最终得出性能结果来评估系统的性能指标是否满足既定值。
• 在性能测试的概念中，性能指标、性能模型、性能场景、性能监控、性能实施、性能报告，这些既是概念中的关键词，也可以说是性能测试的方法和流程。

image image

二、怎么理解TPS、QPS、RT、吞吐量这些性能指标？

TPS 是性能领域中一个关键的性能指标概念，它用来描述每秒事务数。我们也知道 TPS 在不同的行业、不同的业务中定义的粒度都是不同的。所以不管你在哪里用 TPS，一定要有一个前提，就是所有相关的人都要知道你的 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）

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

一般情况下，我们会按从上到下的顺序一一地来测试，这样路径清晰地执行是容易定位问题的。

响应时间 RT

响应时间的概念简单至极，但是，响应时间的定位就复杂了。性能测试工具都会记录响应时间，但是，都不会给出后端链路到底哪里慢。经常有人问问题就直接说，我的响应时间很慢。问题在哪呢？在这种情况下，只能回答：不知道。

对于响应时间来说，时间的拆分定位是性能瓶颈定位分析中非常重要的一节。但是请注意，这个环节并不是性能测试工程师的最后环节。在工作中，我经常看到有很多性能测试工程师连时间拆分都不做，只报一个压力工具中看到的响应时间，就给一个通过不通过的结论，丝毫没有定位。另外，有一些性能测试工程师，倒是用各种手段分析了时间的消耗点，但是也觉得自己的工作就此结束了，而不做根本原因的分析或协调其他团队来分析。当然在不同的企业里，做分析的角色和要求各不相同，所以也要根据实际的企业现状来说。

QPS，如果它描述的是数据库中的 Query Per Second，其实描述的是服务后面接的数据库中 SQL 的每秒执行条数。如果描述的是前端的每秒查询数，那就不包括插入、更新、删除操作了。显然这样的指标用来描述系统整体的性能是不够全面的。所以不建议用 QPS 来描述系统整体的性能，以免产生误解。

RPS（Request per second），每秒请求数。如果一个用户点击了一次，发出来 3 个 HTTP Request，调用了 2 次订单服务，调用了 2 次库存服务，调用了 1 次积分服务，那么这个 Request 该如何计算？如果你是算 GDP 的专家，我觉得可能会是：3+2+2+1=8（次）。而在具体的项目中，我们会单独描述每个服务，以便做性能统计。如果要描述整体，最多算是有 3 个 RPS。如果从 HTTP 协议的角度去理解，那么 HTTP Request 算是一个比较准确的描述了，但它本身的定义并没有包含业务。如果赋予它业务的含义，那么用它来描述性能也是可以的。

HPS（Hits Per Second），每秒点击数。Hit 一般在性能测试中，都用来描述 HTTP Request。但是，也有一些人用它描述真正的客户在界面上的点击次数。关于这一点，就只有在具体的项目中才能规定得具体一些。当它描述 HTTP Request 时，如果 RPS 也在描述 HTTP Request，那这两个概念就完全一样了。

CPS/CPM：Calls Per Second/ Calls Per Minutes，每秒 / 每分钟调用次数。这个描述在接口级是经常用到的，比如说上面的订单服务。显然一次客户界面上的点击调用两次。这个比较容易理解。但是，在操作系统级，我们也经常会听到系统调用用 call 来形容，比如说用 strace 时，你就会看见 Calls 这样的列名。

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

image

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

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

image

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