性能工程：应用指标

性能工程实践，第一步是技术选型，其次是最重要的一步：理解指标。指标根据应用层级不同，可分为应用级指标、系统级指标、数据库指标、中间件指标、JVM指标等。最常见的当是应用级指标和系统级指标，而我们在学指标的过程中，最先接触到的恐怕是应用级指标。以至于不少初学者认为，应用级指标就是唯一维度的指标。

当然，在压测工具端，其实我们最关心的应用级指标实际上只有三个指标：吞吐量、响应时间和成功率（或错误率）。如果压测过程中接口不报错的情况下，事实上，施压端我们关注吞吐量和响应时间就足够了。下面就简单聊聊一下常见的应用级指标。

1、吞吐量（TPS）

吞吐量，在IT领域，和吞吐率是同一个概念，虽然学术上会有比较严格的区分。指的是单位时间内能够完成的事务数量，用TPS表示（Transactions Per Second）。

在Locust性能工具或者阿里压测平台PTS中，衡量系统吞吐量能力的指标是RPS，即Requests Per Second，注意，这里是Requests，不是Responses，这是初学者很容易忽视的地方。

比较费解的是，Requests是客户端线程（协程）产生的，是不是意味着线程数越多，单位时间内可发出的Request请求就越多，RPS也就越多了呢？其实不然。

网络上有个公式RPS=并发用户数 / 响应时间，RPS除了受并发用户数影响，还受响应时间制约。RPS的机制，就是既然1s内服务器的TPS可以有这么多，那么客户端就可以继续发等量的请求，默认服务端可以处理得过来。当响应时间变长了，那么压力产生器就会根据服务端服务能力调整Request请求的产生频率，以做到按照被压测端需要达到TPS等量设置相应的RPS。

不过，该公式其实有个缺点，当大量请求的响应时间方差较大时，用RPS去衡量TPS，会出现比较大的偏差。

2、响应时间（RT）

响应时间反映了完成某个操作所需要的时间，其标准定义是“应用系统从请求发出开始，到客户端接收到最后一个字节数据所消耗的时间”。响应时间的越短越好，是建立在场景正确、服务无异常的基础之上的。如果压测的场景不符合业务，返回的不是正确的业务数据，那么可以认为压测结果是无效的。

在压测过程中，最关心的并不是平均响应时间，而是90/95线和最大响应时间。90线，即按照所有请求的响应时间升序，取前90%中最后一个请求的响应时间，这时间的意义在于找出耗时较长的请求，避免真正的性能问题被掩盖。而响应时间较大的，可以用来做一个链路上分析的示范性实例，有利于快速定位问题。

3、成功率

成功率，分为请求成功率和业务成功率。请求成功率，一般通过返回状态来判断即可；业务成功率，需要判断业务数据返回是否符合预期。

接口返回的状态码，并不能正确反映服务器真实的处理情况的，因为有可能状态码是开发人员人为定义返回的。返回的状态码正常，只能说明，通过了代码的执行逻辑而已，万一代码逻辑本身就是错的或者状态码是没有经过严格定义的呢？而通过断言判断业务数据是否符合预期，更能保证请求是否是真的成功地跑了实际业务的。很显然，业务成功率更有实际价值。

4、并发用户数

性能工具中，并发模式的并发用户数，一般指的是并发线程产生的虚拟用户数量。一个线程产生多少TPS，取决于系统的响应时间有多快。

在系统达到瓶颈之前，因响应时间比较稳定，RPS和并发线程数是成一定的线性关系的，线程数越多，RPS越大；当系统到了瓶颈，这种平衡就要打破了，主要是因为响应时间变长了。

以上就是应用级常见的4个指标，当然还有其他方面的指标，这需要大家额外学习了，这里就不展开了。简简单单的指标，还是有很多学问的，多实践，才会有更深的感悟。