基于最小业务单元的Web系统性能测试调优

（江苏省软件产品检测中心，江苏 南京 210012）

0 引言

网络服务已经是信息化技术下必不可少的重要方式，其性能的好坏将影响着其承载工作的服务效果。作为网络服务的重要构成部分，借助承载服务设备Web Server的关键性势必不言而喻。为确保其可以稳定高效的带来网络服务，运维项目师对其性能展现与优化方法非常重视。针对某个Web Server展开评价，能够从两个层面来看：其一，面向客户，客户体验要好；其二，面向本身，对系统所依靠的硬件设备需物尽其用，充分使用。而以往的Web性能评估指标仅能体现以上两个方面的某个部分，不精准的基础上对两方面展开整体评估，有一定优点也有一些不足。

1 性能测试分析

借鉴格雷格对系统功能的界定，性能检测是面向被测系统软硬件结构、网络条件、业务逻辑与业务环境，对系统的时间属性与资源性质等展开分析检测，发现系统性能问题，且确定问题获得处理的过程。

一个常见的Web系统结构从后至前逐一包含：信息库服务器、WWW服务器、客户终端，就客户角度来讲，系统性能即对客户处理的响应时间。当客户点击一个开关，从客户点击该开关应用系统将此次处理的结果根据客户可以看见的方式呈现出来，该环节所需的时间即客户对系统性能直观记忆，若这一时间太长或返回结果不准确就表示该系统有瓶颈。

2 依靠最小业务单元创建压力测试环境办法的提出

2.1 常规系统性能瓶颈与定位办法

借鉴CSDN的《常规的性能瓶颈与分析过程专题》，根据个人测试操作实际，归纳了当下典型的性能瓶颈种类与定位办法。为了方便在实践过程处理，对某些种类实施了合并。

2.2 依靠最小业务单元创建测压环境的办法

2.2.1 传统办法在确定性能瓶颈方面的限制

监测工具与日志分析仅能确定普通的软件性能瓶颈，找出应用软件与信息库编程漏洞就要求录制压力检测环境，开展测压工作以确定潜在的性能瓶颈。在以往的性能环境录制过程，是尽量的模拟现实的业务环境，尽量可以一网打尽发现全部的性能问题。

另外，还能够在“动态页面、考虑时间、限时放弃浏览等客户特点”方面展开考虑，提高测压环境加载状态下对业务仿真的逼真度。基于这种指导观念，脚本录制环节也是尽量还原现实的业务办理场景与时间顺序，但在确定瓶颈方面通常不如人意。主要原因在于，当同时有先后两个至上系统瓶颈时，于测压过程不管如何增压，因为前面出现的瓶颈限制了测压设备的迭代速率，后面的系统瓶颈将一直不会显露出来，这就干扰了测试与调优效率。

2.2.2 依靠最小业务单位创建测压环境的基本思路

本文主要从最小业务单位着手，将可能干扰系统性能的条件控制在最小时间范畴与相关因素内[1]。基于此，经研究被测应用系统的业务逻辑，根据序列把业务单元组成存在前置关系和没有前置关系的某个业务单元序列。各业务单元序列看作一个测压环境逐步展开测压，且把存在业务逻辑关系的测压结果进行比较，如此就可以迅速确定故障点与瓶颈。

3 实验检测及分析

实验选择了2台虚拟机，主要用作运转Nginx软件与压测设备。压测设备选用Webbench，一个轻量级网站压测产品。其工作原理为：父进程fork许多子进程，各子进程于客户需求时间和默认时间内基于GET信号对目标Web反复传出具体访问请求。实验选择虚拟机配备与运转系统版本状况见表1所示。

表1 虚拟机配备与运转系统版本状况

在压测环节，选择实时软件监控设备mpstat监测运转Nginx的Linux平台的CPU状态，检查CPU统计数据。在多逻辑CPU软件内，其不仅可以呈现CPU的数据还可以查看全部的CPU平均状态数据[2]。Webbench的父进程于全部子进程退出后将统计并呈现出最终检测结果，再退出。利用这两个工具可以获得当下软件的CPU资源应用量与页面下载速率。

统计各不同work-processes值条件下，CPU应用率与页面下载速度，且计算获得COPD值。借助matplotlib与numpy等系统，制作出worker-processes值和COPD指标的联系。

当worker进程数超过逻辑CPU数目时，因为系统内自身无什么进程与worker争夺CPU时间片，因此就算worker进程数增多也不会有正面作用。反而因为进程数的增加，多了多余的进程转换，COPD的分子无谓加大，令指标表现更加差一点。

图1上COPD值顺着横轴类似单调递减，表示在X的取值区间中CPU应用率越大COPD值越小。由于Linux系统内分布的对外服务仅有Nginx，且无其他需要大量资源的进度与worker进度竞争，优先级调整对worker进度获得CPU时间片没有过大影响[3]。若实际条件下Nginx和其他服务运转于同个主机上，能够按照以上方案实际检测，明确优先级怎样设置。

总之，对于Nginx的COPD的提高完善，能够聚集在CPU应用率方面。在具体业务中，能够观察软件业务高峰期稳固的CPU应用率。故worker-processes取值的运算公式可以是：

如此不仅可以符合原来业务的需求，还能够提效。就worker-priority来说，若Nginx运转的系统上没有分布其他应用，将之保留默认值就行。

4 测试结果探究

4.1 依靠最小业务单位的检测与调优方式

本实例的首次“测试-调优”循环过程发现：“客户登录、内部信息核实、内部中心记录核实、业务上交”都有超时情况，再交给各研发小组同步实现针对性调优。因为依靠最小业务单位确定的测压环境，促使各研发小组成员可以随时检测所管理模块的调优成效，而不能等待负责前置要求功能模块的研发小组先调优[5]。

等各研发小组做好各自模块调优工作后，再开始一次包括全部最小业务单位压力条件的回归检测。通过两次检测与循环调优后，调优后的系统满足了检测依据标准。

4.2 传统模拟工作场景的检测与调优方式

作为对比方法，若测压场景简单模拟实际工作场景展开设置将会发现，最初检测时仅仅是“客户登录”超时，待负责登录的研发小组处理了“客户登录”故障后，充分检测又发现“内部信息核实”超时或错误；负责小组处理了“内部信息核实”故障，重新检测又找出“部中心记录核实”超时；处理了“部中心记录核实”故障，才得知大并发客户下“业务上交”偶然会出现错误[5]。如此不仅延迟了调优进度，而且若这些有瓶颈的业务存在相互作用与耦合联系的话，问题将越来越复杂。

5 结论

本文探究了性能测试过程的重要问题之一即确定性能瓶颈的各种内容，分析了依靠最小业务单元创建灵活的测压环境，进而加速找到软件瓶颈的办法。系统性能检测与调优紧密联系，在一个常见的性能测试与调优活动中，利用IBM系统研制成本估算模型。怎样高效地找到性能瓶颈，进而节约测试和调优时间，以减少研发成本，一直是个需要着重探究的问题。