性能理论-软件性能的基本指标（三）

性能测试指标细分为业务指标、资源指标、应用指标、前端指标。

• 业务指标

  并发用户数、TPS（系统每秒处理事务数）、成功率、响应时间

• 资源指标

  CPU 资源利用率、内存利用率、I/O

• 应用指标

  空闲线程数、数据库连接数、GC/FULL GC 次数、函数耗时等。

• 前端指标

  页面加载时间，网络时间（DNS，连接时间、传输时间等）。

性能测试指标总的可以划分为业务指标和系统资源指标两大部分。对于一般用户而言，对于系统性能的要求主要是业务指标，而系统资源指标是系统性能的一个反应，它可以帮助分析系统性能瓶颈、优化系统或者发现一些隐性问题。

对于业务指标的要求主要是请求响应时间、最大并发量等。

对于系统资源的指标，例如，资源使用率，是指在系统负载运行期间，数据库服务器、应用服务器、Web 服务器的 CPU、内存、硬盘、外置存储、网络带宽的使用率。低于 20% 的使用率为资源空闲，20% ~ 60% 的使用率为资源使用稳定，60% ~ 80% 的使用率表示资源使用饱和，超过 80% 的资源使用率必须尽快进行资源调整和优化。

1. 业务指标

业务指标是对软件系统业务处理能力及响应速度的衡量值，是软件系统性能表现的最直观体现。

下面来了解一些性能测试中常见的业务指标。

1.1. 响应时间 Response Time

要理解响应时间，首先需引入事务的概念。事务是指用户在客户端做一种或多种业务所需要的操作集。

响应时间就是对事务操作时间的测量。

事务响应时间 Transaction Response Time 从客户端发起一个请求开始，到客户端接收到从服务器端返回的响应结束，整个过程所耗费的时间。此响应时间不包含客户端 GUI 时间（例如浏览器解释页面所消耗的时间）。

对于软件系统来说，通过事务得到的系统响应时间也是由很多部分组成的。一般来说，响应时间由网络时间、服务器处理时间、网络延迟三大部分组成。首先来看从客户端发出请求到服务器返回需要经历哪些过程。

1. 网络时间

   • 客户端发出请求首先通过网络来到 Web Server 上（消耗时间为 N1）
   • Web Server 将处理后的请求发送给 App Server（消耗时间为 N2）
   • App Server 将操作数据指令发送给 Database（消耗时间为 N3）
   • Database 将查询结果数据发送回 App Server（消耗时间为 N4）
   • App Server 将处理后的页面发送给 Web Server（消耗时间为 N5）
   • 最后 Web Server 将 HTML 转发到客户端（消耗时间为 N6）

   这里的 Nx 都是网络传输上的时间开销，没有计算业务处理所需要花费的时间。

2. 服务器处理时间

   另外还要考虑各个服务器处理所需要的时间 WT、AT、DT。

3. 网络延迟

   除了上面两种时间开销，还要考虑网络延迟的问题。

所以最终的响应时间组成为：

响应时间 = 网络延迟时间 + WT+AT+DT + N1+N2+N3 + N4+N5+N6 + WT+AT+DT

• 参考标准

  不同行业不同业务可接受的响应时间是不同的，一般情况，对于在线实时交易：

  • 互联网企业：500 毫秒以下，例如淘宝业务 10 毫秒左右。
  • 金融企业：1 秒以下为佳，部分复杂业务 3 秒以下。
  • 保险企业：3 秒以下为佳。
  • 制造业：5 秒以下为佳。

1.2. 系统处理能力

系统处理能力是指系统在利用系统硬件平台和软件平台进行信息处理的能力。

系统处理能力通过系统每秒钟能够处理的交易数量来评价，交易有两种理解：

• 一是业务人员角度的一笔业务过程；
• 二是系统角度的一次交易申请和响应过程。

前者称为业务交易过程，后者称为事务。两种交易指标都可以评价应用系统的处理能力。一般的建议与系统交易日志保持一致，以便于统计业务量或者交易量。系统处理能力指标是技术测试活动中重要指标。

一般情况下，用以下几个指标来度量：

• HPS（Hits Per Second）：点击率。每秒点击次数，单位是次/秒

  HPS 主要指每秒客户端向 Web 服务器提交的 HTTP 请求数。客户端每发送一个请求，服务器就处理一次，所以点击数是 Web 应用处理交易的最小单位。HPS 越大，对服务器的压力相对也越大。

  这里需要区别的是，点击不是指日常使用鼠标的单击操作，因为在一次单击操作中，客户端可能向服务器发起了多个 HTTP 请求。

  HPS 除受程序处理速度的影响，还受带宽的限制，即每个请求的大小情况。请求越小，每秒完成的请求数越多。在排除带宽影响的情况下，具有缓存机制的系统比没有缓存机制的系统 HPS 要高很多。在网络传输到达一定程度后，HPS 就不会随并发量的增长而增大。

  一般可以在限定的带宽情况下对最大 HPS 进行估算，公式如下：

  最大HPS = 带宽 / 8 / 估算平均每个请求大小

  带宽好比公路的宽度，网速好比车流的速度。带宽基本单位比特，简写为小写字母b，更大的单位是：Kb、Mb、Gb 等；网速基本单位字节，简写为大写字母B，更大的单位有：KB、MB、GB 等。

  100Mb / 8 / 5KB = 12.5MB / 5KB = 12.5 * 1024 / 5 = 2560

  一般来说，日访问量是在 HPS 基础上计算出来的，公式如下：

  日访问量 = HPS * 3600 * 日访问小时数（可按 8 小时算）

• QPS（Queries per Second）：系统每秒处理查询次数，单位是次/秒

  每秒查询率，是一台服务器每秒能够响应的查询次数，是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。它代表的是服务器的机器的性能最大吞吐能力。

• TPS（Transaction per Second）：系统每秒处理交易数，单位是笔/秒

  TPS = 脚本运行期间所有事务总数 / 脚本运行时长

  TPS 反映了系统在同一时间内能够处理业务的最大能力。TPS 会受到负载的影响，也会随着负载的增加而逐渐增加。当系统进入繁忙期后，TPS 会有所下降，而在几分钟后开始出现少量的失败事务。

对于互联网业务中，如果某些业务有且仅有一个请求连接，那么 TPS=QPS=HPS，一般情况下用 TPS 来衡量整个业务流程，用 QPS 来衡量接口查询次数，用 HPS 来表示对服务器点击请求。

• 参考标准

  无论 TPS、QPS、HPS, 此指标是衡量系统处理能力非常重要的指标，越大越好。

  对于已上线系统：可选取高峰时刻，在一定时间内（如 3-10 分钟），获取系统总业务量，计算单位时间（秒）内完成的笔数，乘以 2-5 倍作为峰值的 TPS，例如峰值 3 分钟内处理订单 18 万笔，平均 TPS 是 1000，峰值 TPS 可以是 2000-5000。

  对于新系统：没有历史数据作参考，建议通过业务部门进行评估。根据经验，一般情况下：

  • 金融行业：1KTPS ~ 5WTPS，不包括互联网化的活动
  • 保险行业：100TPS ~ 10WTPS，不包括互联网化的活动
  • 制造行业：10TPS ~ 5KTPS
  • 互联网电子商务：1WTPS ~ 100WTPS
  • 互联网中型网站：1KTPS ~ 5WTPS
  • 互联网小型网站：500TPS ~ 1WTPS

  TPS 可以参照同行业系统和结合具体业务，中小企业 TPS 值为 50 ~ 1K 笔/秒，银行 TPS 值为 1K ~ 5W 笔/秒，淘宝 TPS 值为 3W~30W 笔/秒。

1.3. 吞吐量 Throughput

吞吐量为单位时间内系统处理的客户请求的数量，直接体现软件系统的性能承载能力。

对于交互式应用系统来说，吞吐量反映的是服务器承受的压力；在容量规划的测试中，吞吐量是一个重要指标，它不但反映在中间件、数据库上，更加体现在硬件上。

• 从业务角度看，吞吐量可用请求数/秒、页面数/秒、人数/天或处理业务数/小时等单位来衡量；
• 从网络角度看，吞吐量可以用字节/秒来衡量。

对于交互式应用来说，吞吐量反映的是服务器承受的压力，它能够说明系统的负载能力。

以不同方式表达的吞吐量可以说明不同层次的问题。

例如：

• 以字节/秒的方式，可以表示要受网络基础设施、服务器架构、应用服务器制约等方面的瓶颈；
• 以请求数/秒的方式，表示主要是受应用服务器和应用代码的制约体现出的瓶颈。

经常在网上看到吞吐量与吞吐率的概念，也有不少人把两者混淆。

• 吞吐量是指单位时间内系统处理的请求数量，能直接反映服务器承受的压力，是需要重点关注的指标。
• 吞吐率一般指用户在给定的一秒内从服务器获得的数据量，简而言之就是服务器返回的数据量。

1.4. 并发用户数 Virtual User

• 系统用户数：简单地说就是该系统的注册用户数
• 在线用户数：即登录系统的用户
• 并发用户数：是对服务器产生压力的用户

例如一个邮件系统，有 100 个注册用户，那么系统用户数就是 100 个；其中一段时间内有 80 个用户登录使用，在这段时间内在线用户数就是 80。

但其中有 10 个用户在阅读邮件内容，20 个用户在写邮件，这 30 个用户在此阶段对服务器并没有产生压力。只有产生了请求、提交等业务操作的用户才会对服务器构成压力。

所以并发用户数是指在系统运行期间同一时刻进行业务操作的用户数量。一般应用系统并发用户数为在线用户数的 10%~20%，但还是要取决于具体的业务逻辑、业务场景。

1.5. 最大并发用户数

最大并发用户数是指应用系统在正式环境下所能承受的最大并发用户数量。

在运行中，如果出现了频繁业务操作失败、响应时间远远超出用户所能承受的最大值或出现了服务器宕机等情况，则说明系统承载量已经超出了最大并发用户数的范围。

• 先了解一个而简单的例子

  TPS 是每秒事务数，但是事务是要靠虚拟用户做出来的，假如 1 个虚拟用户在 1 秒内完成 1 笔事务，那么 TPS 明显就是 1；

  如果某笔业务响应时间是 1ms, 那么 1 个用户在 1 秒内能完成 1000 笔事务，TPS 就是 1000 了；

  如果某笔业务响应时间是 1s, 那么 1 个用户在 1 秒内只能完成 1 笔事务，要想达到 1000TPS，至少需要 1000 个用户；

因此可以说 1 个用户可以产生 1000TPS，1000 个用户也可以产生 1000TPS，无非是看响应时间快慢。

系统的性能由 TPS 决定，跟并发用户数没有多大关系。系统的最大 TPS 是一定的（在一个范围内），但并发用户数不一定，可以调整。

• 对于已有系统

  可选取高峰时刻，在一定时间内使用系统的人数，这些人数可认为是在线用户数，并发用户数可以取 10%。

  例如在半个小时内，使用系统的用户数为 10 万，那么取 10%（即 1 万）作为并发用户数基本就够了。

• 新系统

  没有历史数据作参考，建议通过业务部门进行评估。

  一般情况下，大型系统（业务量大、机器多）做压力测试，1W ~ 5W 个用户并发，中小型系统做压力测试，5K 个用户并发比较常见。

1.6. PV

PV 即 page view，页面浏览量。

用户每一次对网站中的每个页面访问均被记录 1 次。用户对同一页面的多次刷新，访问量累计。通常是衡量一个网站甚至一条网络新闻的主要指标。

与 PV 相关的还有 RV，即重复访问者数量（repeat visitors）。

1.7. UV

UV 访问数（Unique Visitor）指独立访客访问数，统计 1 天内访问某站点的用户数（以 cookie 为依据），一台电脑终端为一个访客。

可以理解成访问某网站的电脑的数量。网站判断来访电脑的身份是通过来访电脑的 cookies 实现的。如果更换了 IP 后但不清除 cookies，再访问相同网站，该网站的统计中 UV 数是不变的。如果用户不保存 cookies 访问、清除了 cookies 或者更换设备访问，计数会加 1。一天内相同的客户端多次访问只计为 1 个访客。

2. 资源指标

资源指标与硬件资源消耗直接相关，也就是所谓的资源利用率。测试的目的不同，需要统计的系统资源指标也不同，主要包括服务器操作系统资源使用情况、资源消耗情况等。

2.1. 处理器

1. CPU 占用率：CPU Utilization Linux

   CPU 利用率 : Processor/Processor Time

   如果该值持续超过 95%，则表明瓶颈是 CPU。可以考虑增加一个处理器或更换一个更快的处理器。一般可接受的最大上限是 80%~85%，合理使用的范围在 60%~70% 以下。

2. 处理器队列长度：System/Processor Queue Length

   如果 System/Processor Queue Length 大于 2，而处理器利用率（Processor Time）一直很低，则存在着处理器阻塞。

   CPU 资源成为系统性能瓶颈的征兆：

   • 很慢的响应时间（slow response time）。
   • CPU 空闲时间为零（zero Percent idle CPU）。
   • 过高的用户占用 CPU 时间（high Percent user CPU）。
   • 过高的系统占用 CPU 时间（high Percent system CPU）。
   • 长时间的有很长的运行进程队列（large run queue size sustained over time）。

2.2. 内存 RAM Memory

1. 内存页交换速率：Paging Rate Linux

   如果该值偶尔走高，则表明当时有线程竞争内存。

   如果该值持续很高，则内存可能是瓶颈，也可能是内存访问命中率低。

2. 可用字节数：Memory/Available Bytes

   Memory/Available Bytes 计数器的值持续降低，同时 Process/Private Bytes 计数器和 Process/Working Set 计数器的值在长时间内持续升高，则很可能存在内存泄漏。需要更详细的内存监控工具来定位是否有内存泄漏和存在内存泄漏的代码。

   内存资源成为系统性能瓶颈的征兆：

   • 很高的换页率（high pageout rate）。
   • 进程进入不活动状态。
   • 交换区所有磁盘的活动次数很高。
   • 很高的全局系统 CPU 利用率。
   • 内存不够出错（out of memory）。

2.3. 磁盘 I/O

1. Disk Rate：磁盘交换率 Linux

   如果该参数值一直很高，则表明 I/O 有问题。可考虑更换更快的硬盘系统。

2. LogicalDisk/Disk Time 和 LogicalDisk/Avg.Disk Queue Length

   当这两个值很高，而 Page Reads/sec（页面读取操作速率）很低时，则可能存在磁盘瓶颈。

   I/O 资源成为系统性能瓶颈的征兆：

   1. 过高的磁盘利用率（high disk utilization）。
   2. 太长的磁盘等待队列（large disk queue length）。
   3. 等待磁盘 I/O 的时间所占的百分率太高（large Percentage of time waiting for disk I/O）。
   4. 太长的运行进程队列，但 CPU 却空闲（large run queue with idle CPU）。
   5. 太高的物理 I/O 速率 [large physical I/O rate（not sufficient in itself）]。
   6. 过低的缓存命中率 [low buffer cache hit ratio（not sufficient in itself）]。

2.4. 带宽

一般使用计数器 Bytes Total/sec 来度量。Bytes Total/sec 表示为发送和接收字节的速率，包括帧字符在内。判断网络连接速度是否是瓶颈，可以用该计数器的值和目前网络的带宽进行比较。

判断网络带宽是否是系统运行性能瓶颈的首要条件是，网络带宽是否会影响系统交易执行性能。

例如，减小网络带宽，并发用户数、响应时间与事务通过率等性能指标是否不能接受；增加网络带宽，并发用户数、响应时间与事务通过率等性能指标会得到明显提高。

在实际性能测试中，如果发现始终报连接超时，而实际手工访问可以正常访问，可以通过 ping 应用服务器 IP 或网关 IP，如果出现网络严重延迟或丢包，则说明网络不稳定，需要检查网络。