性能指标之服务指标

服务指标指的是，计算机系统作为提供服务的一方，对外、对客户提供服务时的指标。最重要的指标是响应时间和吞吐量，在工作中，经常遇到有人错误地理解响应时间和吞吐量之间的关系，本章介绍一下这两个概念以及他们之间的关系。

响应时间

1.概念

从用户的角度看，完成一笔交易、一个事务或者一个操作的时间。

这里的用户是一个泛指，可能是人类用户，也可以是调用这个服务的计算机程序。比如，终端人类用户进行一次页面查询，从发起请求到得到结果的响应时间，服务器开放端调用大机端CICS服务的响应时间、应用服务器调用数据库服务器做一个插入动作的响应时间、数据库锁等时间等等。

2. 统计指标

常见的统计指标有：

整个交易流程的响应时间：适用于交易系统

ETL的时间：适用于统计分析系统

SQL执行时间、数据库等锁时间：适用于含数据库的系统

通常情况下，统计响应时间的最小值、最大值、平均值，其中以平均值作为系统的重要性能指标。

有时，响应时间中有几个最大值把平均值拉高太多，而这些最大值是某些异常情况导致，此时也会采用中位数代替平均值，作为系统的重要性能指标；或者去掉几个最大值之后取平均值，anyway，这些都是数字游戏。

统计学在数学体系里面就是呵呵。

3. 统计方法

针对不同的响应时间，采用不同的统计方法

3.1 系统自身统计

如果您需要的统计值，被测软件或被测系统自身就能够提供，那是最好不过的。系统自身提供的响应时间，其面向的用户都是系统程序，而不是人类用户。

例如大机运行过程中产生的日志，含有CICS响应时间、DB2锁等时间、DB2响应时间、开放端AIX的磁盘读写服务时间、Oracle的AWR报告中SQL执行时间等等各类响应时间。

但需要注意的是，以性能统计为目的的数据收集，不能明显影响系统性能，例如开trace会让系统性能指标严重变形，这种情况下的响应时间不是常态的响应时间。

3.2 性能测试工具统计

若要统计人类用户感知的响应时间，那么需要性能测试工具（LoadRunner、JMeter等）模拟用户行为，从请求发起直至结果返回的一个同步调用过程。

LoadRunner、JMeter等性能测试工具的统计，适用于同步调用的统计，不一定适用于异步的统计。简单来说，就是一个虚拟用户（vu）的进程/线程发起请求后需要一直等着它的结果返回，在一个进程的处理过程中的两个时间戳做差，得出响应时间。

异步场景指的是进程发出请求后就完成了本次任务，至于接收结果是另一个进程来处理，并且，接收的结果可能发送到了另一台性能测试压力机上。

之所以LoadRunner、JMeter等为代表的性能测试工具不一定适用于异步场景的统计，最主要的原因是，结果如果发送到另一台压力机，而不同压力机的时间是有差异的。我们完全可以在发送请求时，记录时间戳并写入日志或数据库；接收结果的时候，也记录时间戳并写入日志或数据库。

但不同压力机的时间差不可避免，即使采用NTP时钟同步，或者人工同步几台压力机的时间，但这种同步是秒级的同步，而性能测试中的响应时间大多是毫秒级的。比如说一笔业务20ms结束，如果两个机器的时间差大于2ms，那么统计出来的响应时间就不太准确了，如果时间差大于20ms，就会出现结束时间早于发起时间的问题。

如果可以容忍秒级的时间差，那么这种方法对异步交易还是可行的。

3.3 日志统计

日志统计是通过应用程序自身打印的交易开始时间、结束时间，通过事后采用统计工具进行响应时间统计的方法。日志统计中的开始时间、结束时间均来自同一台服务器。

有两种情况下，适用于日志统计响应时间的方法。

一是不需要统计一个交易在网络上的耗时；

二是异步交易，1）发生在同一台服务器上，2）发生在不同服务器上，但可以容忍秒级的统计误差。

日志统计方法有它的不足之处：日志统计需要应用程序启动后才能打印日志，这就漏掉好多的处理过程。比如用户通过传输中间件（如MQ）发起一笔交易，整个流程包括MQ报文在传输队列中的等待、网络传输、MQ报文在对端本地队列中的等待、报文被应用读取并处理、返回报文传输队列中的等待、返回的网络传输、返回报文在本地队列中的等待。应用日志统计仅能统计“报文被应用读取并处理”的响应时间。

有人想到，通过MQ日志可以查看这个报文是什么时候从对端发出来的，这样就可以计算该报文传输的时间，但MQ当中的“报文发送时间”也是上一个节点服务器打印的时间，同样存在不同服务器之间时间差的问题。

因此，由于不同机器之间存在时间差，日志统计法不太适用于跨机器、跨节点的统计，除非可以容忍秒级的时间误差。

3.4 网络抓包设备统计

为了能够统计更接近用户体验的、接近全流程的响应时间，可以采用网络抓包设备在各个网络端口处进行抓包，并将抓取到的数据包发送到同一台抓包设备。

抓包设备只有一台，因此可以避免时间差。有人会问，压力机要多台，而抓包设备就可以一台？这是因为压力机需要处理较多的逻辑，相对来说比较消耗CPU，因此单台压力机单位时间内能够发送和接收的交易数量是很有限的，一般每秒钟几百笔业务的水平。而网络抓包设备由于没有过多的逻辑处理，每秒上万笔报文可以轻松达到。

同时，通过网络抓包设备中的日志，可以统计出包含网络传输时间在内的响应时间，更接近真实用户的等待时间。

吞吐量

1. 概念

吞吐量是单位时间内完成交易的数量（也称为交易率）或者单位时间内通过的字节数。

交易系统经常用TPS（Transaction Per Second）这个指标。当然，每分钟的交易量、每小时的交易量、甚至每天的交易量也是吞吐量，但由于现在的IT系统承载的业务压力越来越大，衡量一个系统的吞吐量基本上不会采用分钟、小时这样的计量单位。

如果对TPCC/tpmC（衡量交易类系统的指标系统）熟悉的同学应该知道，tpmC这个指标是每分钟的交易数量，这个指标是很早很早之前设定的，因此还在用分钟这个单位。

2. 统计指标

常见的统计指标有：

单位时间内完成交易的数量：适用于交易系统

单位时间内传输报文的数量：适用于传输系统

单位时间内完成SQL的数量：适用于含数据库的系统

单位时间内生成报表的数量：适用于报表系统

单位时间内传输的字节数：适用于各类系统

3. 统计方法

与“响应时间-统计方法”一致，仅需将统计对象由“响应时间”改为“吞吐量”。

响应时间与吞吐量的关系

吞吐量可以理解为单位时间内三环上通过了多少车，响应时间可以理解为每辆车在三环上绕一圈需要多少时间。二者之间有点关系，但并不是简单的数学公式型的关系。

这里通过几个误区的分析来说明二者之间的关系。

误区举例1：某业务响应时间为200ms，计算系统的吞吐量为每秒钟5笔业务（1000ms/200ms）。

分析：这个推导是错误的。推导中忽视了系统的并发处理能力。如果系统是单进程的，并且不处理任何其他业务，那么一个业务200ms，系统每秒处理5笔是差不多的。但是，系统大多是多进程/线程，多CPU，因此如果这个应用是多进程应用，那么理应具有一定的扩展能力，每秒处理的业务数一般情况下是大于5的。但如果应用不具有多进程扩展性，或者受到其他系统进程的干扰，或者任务之间有先后等待，也可能会低于每秒5笔。

误区举例2：某系统的吞吐量为每秒钟100笔业务，计算业务的响应时间为10ms(1000ms/100）

每秒处理100笔业务，不等于每笔业务10ms能够处理完。设想一个场景，每笔业务需要1000ms，但有100个并发进程在100个CPU上运行，那么每秒钟可以处理100笔业务，但响应时间是1000ms。

误区举例3：某系统CPU利用率在40%的时候，吞吐量为每秒100笔，响应时间为20ms，计算CPU利用率在80%的时候，吞吐量为每秒200笔，响应时间20ms。

随着CPU利用率的上升，进程竞争CPU的情况更加严重，响应时间往往会超过20ms，而不是静态的20ms。因此，从单CPU单进程的角度，每秒处理交易量是减少的。

但实测中也经常会发现，CPU利用率翻倍后（达到80%），吞吐量不止增加100%（可能超过200笔每秒）。这是因为，系统运行本身消耗一部分CPU，比如10%。当CPU利用率为40%的时候，有40-10=30%的CPU是真正干活的。当CPU利用率为80%的时候，有80-10=70%的CPU是真正干活的。那么70%比30%上升不止一倍。

总结，吞吐量和响应时间二者之间有一定关联，但由于受到其他的影响因素过多，没有任何公式可以推算系统的吞吐量及响应时间，唯有实测值最准确。

系统并发数

相对于业务指标中的用户并发数。是系统能够同时处理任务的最大并发能力。

这个指标并不是一个重要的指标，在这里提一下的目的在于，便于理解“业务指标-并发用户数”。

举个简单的例子，比如1个进程有10个线程可同时提供服务，则系统并发数是10。如果启动了5个进程，那就是5*10=50的系统并发数。当然，实际的场景会比较复杂，系统并发数受到系统资源的影响、应用/中间件/数据库配置的影响、应用架构的影响等等。

对系统并发数的理解常常有偏差。一个测试场景的vu数并不等同于系统的并发处理能力（即使是设置了N个vu的集合点）。比如100个用户一起点按钮发送请求，如果系统能够正常处理，并不等于说系统并发数是100。比如系统中只有10个线程进行处理，系统的并发数只有10，那么其他的90个用户则是在排队，虽然在排队，但从用户的角度，他们的请求也是被受理了的，只是响应时间变长了而已。在这个场景中，（业务）用户并发数是100，系统并发数是10。