转：性能指标之业务指标

Posted 2020-12-27 ryn3316

经常在系统的需求书当中看到这样的描述“响应时间在3秒以内”，这类需求让测试人员无从下手，这是在多大的并发用户数下面得到这个结果？在多少存量数据的情况下得到这个结果？ 1年、2年？即使随便设置个场景测完了，也不敢出具测试结论。

 

业务指标是从用户操作的角度体现出来的，相对于服务指标。服务指标是从系统对外提供服务的角度设定的指标。主要指标有业务类型、业务配比、并发用户数。

 

在描述一个系统的性能表现时，我们常常采用三段式的表达方法：业务指标-资源指标-服务指标。

 

例如：在处理典型业务AAA与典型业务BBB、二者业务配比为1:3时，当CPU（10C）利用率达到70%时，系统的吞吐量为每秒200笔交易，交易响应时间为80毫秒。

 

只有这“业务指标-资源指标-服务指标”三段论都说齐了，才算一个“相对”可参考的性能结论。之所以称之为“相对”是因为，随便改一个参数都可能对性能造成巨大的影响，任何性能结论都是在审慎的态度下给出的。

 

一、业务类型

 

业务的种类、名称。

不同业务种类的处理逻辑、处理效率不一样，因此需要明确业务类型。

 

二、业务配比

 

不同业务在同一个场景中时，单位时间内数量的比例。

 

三、并发用户数

 

在详细解释并发用户数之前，可能需要分辨一下双方讨论的并发数是“并发用户数”？还是系统并发数？还是在系统中注册的用户数？还是在线用户数？

 

我们知道，已登录的用户不一定有操作。

 

并发用户数的确定必须和业务场景相结合。需要明确是哪个模块的系统并发数，登陆模块？查询模块？下载模板？这些都是不一样的。如果要看混合场景，需给不同模块操作的用户配比。具体但单个模块的场景，需给出用户的发起频率（这个后面还会介绍），比如5分钟操作一次，还是10秒钟操作一次。

 

为什么并发用户数是一个重要的性能指标？

 

最重要的原因是并发用户的数量直接影响了用户自身的体验。任何对系统性能的分析、测试、调优都是以用户为圆心的。当并发数多了的时候，用户感受到的响应时间可能会变长甚至服务中断。原因如下：

 

当每个用户在服务器端都会有一个进程/线程来提供服务，当并发的用户多了之后，进程/线程的调度开销，CPU上下文切换增多，会影响执行效率。

 

当并发的用户多了之后，由于程序的设计原因，可能会多个用户竞争同一个资源，由此产生内存栓锁、数据库锁、信号量等等控制竞争的机制，从用户的角度看到了排队。

 

同时，系统中有最大连接/最大session/最大线程数量的限制。当达到最大值后，更多的用户请求不能接待，产生等待或报错。这些最大值的限制，有些是人工设置的结果（例如最大连接/最大session数），有些是系统自身计算的结果（例如最大线程数）。

 

对于人工设置的最大值是可以调节的，有时调大会起到不错的效果，但并不是所有情况下调大都有正面的作用。人工设置最大值和系统自身计算最大值本质上是一样的，即系统的资源是有限的，总会有一个天花板。

 

以Linux为例，最大线程数是多少是根据系统物理内存数量来计算的（有兴趣可以翻看Linux内核源代码），因为每个线程要开辟一块内存区域给这个线程。

 

有时并发用户数越少，性能反而越差

 

这种情况出现在用户自己等自己的情况，归根结底还是资源的竞争。

 

举例：当系统整体吞吐量相同的时候（每秒10000笔交易），每笔交易修改自身的数据库中的某一个表的固定的一行（例如：账户余额）。

1）100个并发用户，每个用户每秒100笔交易，那么每个数据库的行锁每秒需要锁定100次。

2）10个并发用户，每个用户每秒1000笔交易，那么每个数据库的行锁每秒需要锁定1000次，即所谓的热点账户问题。

 

四、存量数据

 

在数据库或文件系统中，用户已经存储了多少业务数据，比如1年或1000万条等等表达方式。

 

存量数据对用户的增删改查性能有非常明显的影响，在数据库中体现更明显。10个数字当中找一个，和10亿个数字当中找一个难度自然不同。

 

五、发起频率

 

这个指标很少有人关心，但的确对系统性能有些影响。

 

5.1      相同吞吐量下不同的发起频率

 

举个例子，一秒发起100笔报文，可以有不同的发起频率：

1）  每10毫秒发起1笔报文

2）  每100毫秒发起10笔报文

3）  每1000毫秒发起100笔报文

 

这三种发起频率下，系统的吞吐量都是每秒100笔报文，但是系统资源利用率、响应时间等指标会略有差异。

 

试想，火车站有一个售票窗口，如果每隔1分钟来一位旅客，那么每位旅客的等待时间就非常短。而如果每小时的整点一次性来60位旅客，那么旅客的平均等待时间就比较长。

 

在计算机系统中，到底哪种发起频率会响应时间短，与系统的设计有关。假设应用程序设计为，“每凑齐10笔报文读取并处理一次“，那么采用频率1似乎等待的时间更长。有人会问，会有这种逻辑设计吗，其实在系统性能调优的时候，经常有这样的批量处理原则；比如从MQ队列中每次读取10个报文，MQ每10笔commit一次，SQL语句每10笔commit一次，网络中的delayACK（凑齐一个window的数据包再一次性回复ACK）。

 

上面说到了对响应时间的影响，其实发起频率对系统资源消耗也同样存在影响。频率1中，系统只启动一个进程就可以处理，而频率3中，一次性达到100笔报文，应用读取中间件队列的深度后发现一次性的来了100个报文，则决定启动20个进程并发处理，很快处理完成后，这些进程基本都被销毁，只留下1个值班的进程。那么在这个大量创建进程、销毁进程的过程中，CPU消耗是非常大的。

 

总之，在计算机系统中，到底哪种发起频率会响应时间短，系统消耗少，是与系统的设计有关，不能一概而论，唯有实测才最准确。

 

5.2      不同吞吐量下不同的发起频率

 

这个概念比较好理解，一个用户每分钟发起1次请求和10次请求，那么这个用户的发起频率是不同的，同时也影响了吞吐量的不同。

 

对于页面形式的性能测试，在需求书中经常可以看到如下的需求：

“在并发用户数为100的时候，响应时间为3秒以内”

 

从业务指标的角度，这里缺少了一个要素，就是用户发起频率。每个用户是每秒发起1次请求还是10次请求？

 

如果不描述这个发起频率，则需要从系统的角度补充吞吐量指标。

 

关注发起频率的另一个目的是验证服务端是否达到了吞吐量极限。

 

系统的吞吐量没有达到预想的数值，需要首先分析：

1）  是用户没有发出来这么大压力？

2）  用户压力足够，但系统不能完全处理

因此，发起频率不但要关注，并且要可以稳定的压出。这一部分内容会在后续测试工具的章节介绍。