性能测试从零开始

性能测试从零开始——LoadRunner入门与提升第11章定量分析及诊断——建立性能度量模型以loadrunner为主导的性能测试可以获知被测系统的基本性能信息，比如：●被测系统在指定环境下，是否达到预期性能指标？●被测系统是否存在性能瓶颈？这只是对被测系统的一个定性判断，而作为性能测试的专业人员，我们需要给客户更详细更有建设意义的信息，比如：●性能瓶颈存在于被测系统的哪个节点，模块甚至代码行？可以给出解决建议吗？●当前系统经过性能调整后，可以减少多少响应时间？●被测系统上线后，随着数据容量的增加和硬件环境的变化，是否可能遇到性能拐点，又如何应对？●如何在当前的开发测试过程中，避免此类的性能问题将来再次发生？等等。这些问题实际上促使性能测试进入了一个定量分析的层次。简单来说，定性分析主要是“发现问题”，而定量分析不但要“定位问题”，最好还能“解决问题”，甚至要在当下“避免问题”，在将来“预测问题”。对软件系统做性能定量分析是一个高级软件人员的优秀素质，这不仅仅是在LoadRunner层次上纯熟地使用技巧，更需要软件各个领域的深厚专业知识，而且还要有和各个团队角色耐心细致交流的能力。11.1实现性能度量的准备工作11.1.1性能度量显而易见，能够实现性能定量分析的前提是要有数据，而且是详细而全面的性能数据。就像一个医术高明的大夫，往往会在诊断前和病人谈话交流，在充分了解病人的体质、症状、病史之后，才能对症下药，因人施方。度量数据有哪些呢？1．拓扑节点度量数据针对一个B/S四层架构的系统，比较典型的有：●网络性能数据包括当前局域网网络带宽，测试过程中网络的平均流量，峰值流量，占用带宽百分比等。●Web服务器HTTP请求性能数据包括HTTP服务器的基本配置、线程池数目、httpGet/Post请求的个数、响应时间等。●应用服务器交易性能数据交易定义因具体应用而定，一般包括处理的transaction的个数，transaction的处理最大时间、平均时间等。●数据库监控报表数据库的基本配置信息、topSQL、BreakDown等。等等。由上可见，节点度量数据一般都会在系统各个节点上进行采集。这是因为，度量分析的根本目的是将定性测试中得到的整个系统响应时间进行细分，需要知道到底哪个环节模块消耗的资源最大，占用的响应时间最长。我们能分析并定位瓶颈到什么层次，取决于度量数据采集点下钻到达的位置。2．基准环境度量数据在节点度量数据的基础上，将同样的性能测试场景运行在不同的软硬件基准环境下，得出系统的基准环境度量数据，它会反映当前软件系统在何种配置环境下获得最优的性能表现。比如，在不同数据容量配置下，对在线文件管理系统进行性能测试（如表11-1所示）。表11-1数据容量性能度量性能场景200K基础数据400K基础数据600K基础数据800K基础数据UploadFile223ms355ms458ms552msDownloadFile84115151199SearchFile54616266DeleteFile747787903．周期迭加度量数据在节点度量数据的基础上，将同样的性能测试场景运行在软件产品生命周期中各个可测版本上，得出被测产品的周期迭加度量数据，它会反映当前软件系统随着版本的更新而性能变化的趋势。比如，在不同测试版本上，对在线文件管理系统进行性能测试（如表11-2所示）。性能场景8月3日版本8月31日版本9月10日版本9月24日版本UploadFile223ms253254278DownloadFile84979097SearchFile74767880DeleteFile5454555811.1.2度量方式有了度量数据后，我们将采用不同的方式对其进行分析，来达到性能度量的目的。1．使用下钻细分法进行瓶颈定位我们用层层下钻的方式来进行性能的定量分析一级下钻某交易的系统响应时间=客户端处理时间+网络时间+Web服务器时间+应用处理时间+数据库时间案例分析例子：比如某邮件系统的Web发送邮件的总共耗费时间为4秒，根据度量数据，进行一级下钻：●客户端处理时间：浏览器处理时间，忽略●网络响应时间：54ms，相比15S，可以忽略●Web服务器时间：0.56S/HttpRequest●SMTP服务邮件发送处理时间：未知●数据库处理时间：connecttime+Sqlparsetime+sqlexecutetime=1.4S总响应时间=页面时间+网络时间+Web处理时间+SMTP邮件服务处理时间+数据库处理时间4S=0+0+0.56+SMTP应用服务时间+1.4SMTP应用服务时间=40.561.4≈2S二级下钻下面，尝试将SMTP服务时间进一步下钻细分。SMTP服务架构如图11-1所示。图11-1SMTPServiceArchitecture大致可把SMTP处理分为几个阶段：SMTP服务时间=认证时间+SMTPLocalQueue入队时间+Outbound处理时间在各个模块上进行监测，时间细分为2S≈0.02S+1.2S+0.7S。由于JobQueue上花费了1.2S，那么说明邮件队列还有调优的空间。2．使用正交图来预测性能拐点两个因素A和B，B的变化会导致A的变化，那么可以以A为纵轴，B为横轴，建立二维正交图来观察A和B之间的影响作用大小及发展趋势。比如在上面的基准环境度量数据例子中，A为性能响应时间，B为基础容量数据，以uploadfile测试案例为例，可以绘制如图11-2所示的曲线图。图11-2容量—性能变化曲线从以上曲线可知，随着数据容量的增加，性能响应时间增加幅度较少，这是一个斜率小于1的曲线，因此，可以预测在将来容量增加的一段时间内，应该不会存在容量拐点和瓶颈。在上面的周期迭加度量数据例子中，A为性能时间，而B为版本周期。以downloadfile测试案例为例，可以绘制如图11-3所示的曲线图。上面的曲线反映了一个问题，第二个版本相比第一个版本出现了较大幅度的性能衰退，而在第三个版本和第四个版本中得到解决，并加以控制。图11-3版本—性能变化曲线总结数据是性能量化分析最重要的基础和前提。要想做到量化分析，需要在不同的时间和空间内重复执行性能测试，并收集详细而全面的度量数据。在某种程度上来说，没有采集度量数据的性能测试是毫无意义的。案例分析性能bug定量分析实际案例Bug标题：1.1版本升级到1.2后loginaction发生40%的性能衰减。测试环境：某Web订票系统1.2版本。场景描述：50用户ramp并发login运行一个小时，thinktime500毫秒。测试结果：1.2版本LoginService花费时间为4.2秒，而1.1版本同样的场景案例则花费2.4秒。对1.2版本上采集的性能度量数据进行下钻细分，OracleDB的AWRTOPSQLreport捕捉到一条sql语句耗时达1.5秒。Selectusername,passwordfromocs_data.auth_userswhereNLSSORT(username,'NLS_SORT=GENERIC_M_CI')=NLSSORT('ocsadmin','NLS_SORT=GENERIC_M_CI')对比1.1版本的AWRReport，发现这是一条1.2版本新引入的sql语句。1.1版本同样作用的sql语句为：Selectusername,passwordfromocs_data.auth_userswhereusername='ocsadmin'耗时仅为50毫秒。解决建议：新sql语句耗时时间较长，是由于where使用了新的字段表达式，而使得原有的字段索引没有排上用场。建议建立新的字段索引。Bug总结：上面的bug分析逻辑清楚，直接揭示瓶颈根源，定位到了语句级别。能完成这样的量化分析，依赖于以下几个基础条件：●节点数据采集点详细而全面，在oracleDB上使用awr进行sql语句采集，这为sql语句性能分析提供了数据基础。●周期数据持续采集形成对比基准。在1.1和1.2版本中持续进行性能回归测试，直接将新旧版本上topsql进行对比，这为瓶颈定位提供了逻辑条件。11.2案例实践——性能测试第一阶段Ajax页面基准性能分析11.2.1页面基准分析目标基准分析是Ajax性能测试项目实施的第一阶段，其主要目的是考察单个用户使用系统时，用户获得的性能体验，包括响应时间和资源的使用情况，并通过相关工具对性能表现进行细分（BreakDown），从而提前发现客户端和应用服务器上可能存在的性能问题，甚至瓶颈。为第二阶段的并发负载测试提供对比参考依据和技术基础。11.2.2分析所使用的工具本阶段主要采用HttpWatch和IEWebDeveloper两种web客户端细分监控工具来完成基准分析。HttpWatchHttpWatch是一款HTTP网络协议监控分析工具，可以分解各个httprequest的具体响应情况，包括Send，Receive，Method，StatusCode，URL等，如图11-4所示。图11-4HttpWatchIEWebDeveloper是一款性能Web页面DOM分析工具，能够分解页面的各个元素，包括html的标准元素，和JavaScript脚本等，如图11-5所示。图11-5IEWebDeveloper11.2.3术语揭示DownloadData：从Server向客户端的下行数据。UploadData：从客户端向Server的上行数据。TotalTime:完成一次页面切换或提交所花费的时间。JavaScript:运行在浏览器中的脚本语言。BreakDownTime:细分时间。11.2.4基准测试案例设计及运行1．项目介绍某电力信息管理系统负责对所在区域的供电、配电生产等系统上千个节点进行管理验收等工作。本系统使用Extjs框架开发Web页面，后台使用Weblogic应用服务器和Oracle数据库服务器。Extjs框架是比较流行的一种Ajax应用模式，代码表现为一套开源的跨浏览器的JavaScript脚本库，依据Extjs可以构建多种RichWeb客户端应用。但从系统性能的角度来说，使用ajax模式会引发一个性能考虑，那就是由于浏览器中嵌入了大量的JavaScript逻辑处理运算，使得客户端也有成为性能瓶颈的潜在风险。因此在大并发负载测试开始之前，有必要对客户端的JavaScript进行性能基准分析。本轮测试对将要负载测试的功能点进行基准分析：（1）登录信息系统。（2）点击“电票管理”，展开票单信息页面。（3）点击“新增”，提交票单。注：以上测试均在系统没有负载的情况下，以单用户完成。2．Ajax页面登录功能基准分析本环节的诊断对象为登录功能。即从登录页面输入用户名、密码到登录成功，展现系统主页面结束，监控客户端与服务器之间的交互。登录后页面如图11-6所示。图11-6登录在此过程中，使用HttpWatch和IEWebDeveloper采集到的性能数据如表11-3所示。表11-3性能数据指标性能表现单用户登录花费时间8.123S（秒）发生的httprequest个数188个网络下行数据流量1.9MB网络上行数据流量114KB占用网络带宽平均值2MB/8.123S=246.214KB/S占用网络带宽峰值462KB/S对8.123秒的登录时间进行细分诊断，结果如表11-4所示。表11-4细分诊断诊断对象总共细分过程注登录响应时间8.123S发生七次对ServerAction的调用总共花费时间2.223S其中捕捉到main.do的getFuncNode被重复调用5次下载83个javascirpt文件总共花费时间3.413S其中捕捉到ext-all-debug.js文件高达1.05MB诊断对象总共细分过程注登录响应时间8.123S下载JPG图片等其他资源总共花费时间1.45S注1：被重复调用server的action全路径为http：//192.168.1.1:8080/appframe-web/main.do?method=getFuncNode注2：1.0