|
性能工程实践，第一步是技术选型，其次是最重要的一步：观察指标。指标根据应用层级不同，可分为应用级指标、系统级指标、数据库指标、中间件指标、JVM指标等。最常见的当是应用级指标和系统级指标，而我们在学指标的过程中，最先接触到的恐怕是应用级指标。以至于不少初学者认为，应用级指标就是唯一维度的指标。
当然，在压测工具端，其实我们最关心的应用级指标实际上只有三个指标：吞吐量、响应时间和成功率（或错误率）。如果压测过程中接口不报错的情况下，事实上，施压端我们关注吞吐量和响应时间就足够了。下面就简单聊聊一下常见的应用级指标。
1、吞吐量（TPS）
吞吐量，在IT领域，和吞吐率是同一个概念，虽然学术上会有比较严格的区分。指的是单位时间内能够完成的事务数量，用TPS表示（Transactions Per Second）。
在Locust性能工具或者阿里压测平台PTS中，衡量系统吞吐量能力的指标是RPS，即Requests Per Second，注意，这里是Requests，不是Responses，这是初学者很容易忽视的地方。RPS和TPS还是有区别的，TPS是服务端实际可提供服务的能力；RPS是施压机的压力产生器根据响应时间自动调整请求发出频率，该指标实际上是有一定滞后性的。不过实际应用中，可以简单理解为，RPS=TPS。
比较费解的是，Requests是客户端线程（协程）产生的，是不是意味着线程数越多，单位时间内可发出的Request请求就越多，RPS也就越多了呢？其实不然。压力产生器达到某个并发用户数，但并不是每一秒都有和并发用户数等量的请求发出。
根据公式RPS=并发用户数 / 响应时间，RPS除了受并发用户数影响，还受响应时间制约。当响应时间变长了，那么压力产生器就会根据服务端服务能力调整Request请求的产生频率。
2、响应时间（RT）
响应时间反映了完成某个操作所需要的时间，其标准定义是“应用系统从请求发出开始，到客户端接收到最后一个字节数据所消耗的时间”。响应时间的越短越好，是建立在场景正确、服务无异常的基础之上的。如果压测的场景不符合业务，返回的不是正确的业务数据，那么可以认为压测结果是无效的。
在压测过程中，最关心的并不是平均响应时间，而是90/95线和最大响应时间。90线，即按照所有请求的响应时间升序，取前90%中最后一个请求的响应时间，这时间的意义在于找出耗时较长的请求，避免真正的性能问题被掩盖。而最大响应时间可以用来做一个链路上分析的示范性实例，有利于快速定位问题。
3、成功率
成功率，分为请求成功率和业务成功率。请求成功率，一般通过返回状态来判断即可；业务成功率，需要判断业务数据返回是否符合预期。
接口返回的状态码，并不能正确反映服务器真实的处理情况的，因为有可能状态码是开发人员人为定义返回的。返回的状态码正常，只能说明，通过了代码的执行逻辑而已，万一代码逻辑本身就是错的或者状态码是没有经过严格定义的呢？而通过断言判断业务数据是否符合预期，更能保证请求是否是真的成功地跑了实际业务的。很显然，业务成功率更有实际价值。
4、并发用户数（并发线程数）
性能工具中，并发模式的并发用户数，一般指的是产生虚拟用户的线程的数量，即并发线程数。一个线程产生多少TPS，取决于系统的响应时间有多快。
在系统达到瓶颈之前，因响应时间比较稳定，RPS和并发线程数是成一定的线性关系的，并发越高，RPS越大；当系统到了瓶颈，这种平衡就要打破了，因为响应时间变长了。
以上就是应用级常见的4个指标，当然还有其他方面的指标，这需要大家额外学习了，这里就不展开了。简简单单的指标，还是有很多学问的，多实践，才会有更深的感悟。
|