压力测试工具loadrunner学习总结
- 格式:doc
- 大小:53.50 KB
- 文档页数:4
性能测试学习通过一段时间的性能测试学习,学习到很多新的知识,但是还是颇感自己在这方面的知识欠缺,针对本次学习,我对性能测试指标做下具体的分析和讲解。
性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。
负载测试和压力测试都属于性能测试,两者可以结合进行。
通过负载测试,确定在各种工作负载下系统的性能,目标是测试当负载逐渐增加时,系统各项性能指标的变化情况。
压力测试是通过确定一个系统的瓶颈或者不能接收的性能点,来获得系统能提供的最大服务级别的测试。
性能测试指标的基本概念吞吐量/处理能力处理能力又叫吞吐量,指的是单位时间内处理的客户端请求数量。
通常情况下,吞吐量用请求数/秒 Or 页面数/秒来衡量。
从业务角度看,吞吐量也可以用访问人数/天Or页面访问量/天来衡量。
在此我就针对HP Web Tours 应用程序为例子测试环境:本地计算机本地数据库局域网(1)录制一个订票系统脚本web_submit_data("login.pl","Action=http://127.0.0.1:1080/WebTours/login.pl","Method=POST","RecContentType=text/html","Referer=http://127.0.0.1:1080/WebTours/nav.pl?in=home","Snapshot=t2.inf","Mode=HTML",ITEMDATA,"Name=userSession","Value=102933.096962333fcQtzcVpVHfDVHzHpHcHAf", ENDITEM,"Name=username", "Value=tom", ENDITEM,"Name=password", "Value=123", ENDITEM,"Name=JSFormSubmit", "Value=on", ENDITEM,"Name=login.x", "Value=59", ENDITEM,"Name=login.y", "Value=8", ENDITEM,LAST);(2)添加事务事务(Transaction)是这样一个点,我们为了衡量某个action的性能,需要在action 的开始和结束位置插入这样一个范围,这就定义了一个transaction。
Load Runner 相关概念解析集合点1)集合点用以同步虚拟用户以便恰好同一时刻执行任务。
在没有性能测试工具之前,要实现用户的并发是很困难的,最常见的方法就是把公司的所有或者部分员工召集起来,有一个同志喊123开始。
然后大家一起提交数据。
2)Load Runner的集合点则可以完全实现用户的同步问题,而且可以模拟成千上万的用户操作是轻而易举的事情。
3)集合点的设置方法A.在录制过程中可以设置集合点。
B.在使用Load Runner的Controller进行负载时,可以通过依次选择【Scenario】>【Rendezvous…】项实现。
C.可以选择某个虚拟用户后单击enable rendezvous或disable rendezvous.可以设置许启用或者禁止某个集合点.D.可以设置集合点策略,在Rendezvous information,点击Policy按钮。
这个很重要。
有三种情形。
E.在集合点设计策略窗体中也可以设计集合点释放比例。
还可以设置Timeout between Vusers虚拟用户之间的超时间隔。
一般默认是30秒。
可以根据实际情况进行设置。
事务事务是要度量其服务器响应时间的任务或操作集。
一个完整的事务由事务开始、事务结束以及一个或多个业务操作/任务构成。
重点提示事务必须是成对出现,即一个事务有事务开始,必然要求有事务结束。
不要将Lr_think_time放在事务里,影响分析和统计,除非有特殊的情况需要这么做。
检查点检查点的作用是在回放脚本期间搜索特定的文本字符串或者图片等内容,从而验证服务器响应内容的正确性。
添加检查点方法:切换到脚本数视图,然后在左侧切换到“Server response”页,然后添加一个文本Add a Text check。
也可以检查图片。
P14重点提示检查点设置完成后,要保证检查点能使用,需要在Run Time settings –Preferences >Enable Image and Text check 复选框选上,否则的话检查点失效。
loadrunner8.1操作笔记学习要点一、概述LAODRUNNER8.1 作为专业的性能测试工具,通过模拟成千上万的用户对被测应用进行操作和请求,在实验室环境中精确重现生产环境中任意可能出现的业务压力,然后通过在测试过程中获取的信息和数据来确认和查找软件的性能问题,分析性能瓶颈.LOADRUNNER提供了三个大主要模块,这三个模块既可以作为独立的工具分别完成各自的功能,又可以作为LOADRUNNER的一部分彼此衔接,与其他模块共同完成软件性能的整体测试.这三大模块主要是: VITUAL USER GENERATOR--------用于录制脚本MERCURY LOADRUNNER CONTROLLER---------用于创建,运行和监视场景MERCURY LOADRUNNER ANALYSIS--------用于分析测试结果;二、LOADRUNNER8.1 安装LAODRUNNER8.安装过程比较简单,只需按系统的提示一步一步操作就可以了,这里对安装过程中的一些要点进行简要的说明.安装类型安装盘内有两个盘片,MERCURY LOADRUNNER8.1和MECURY LOADRUNNER 8.0ADD-INS.前者包括了LR安装程序及常用组件,后者全部为组件,各组件的作用在安装盘中都有详细的提示.LICENSE 类型LICENSE类型说明如下:PERMANENT 永不过期的LICENSE;TIME LIMITED 限定了使用的起始时间和使用周期;TEMPORARY 从安装后开始计算,限定了使用的天数;VUD-BASED 限定了虚拟用户数量PLUGGED 需要DONGLE,也就是HARDWARE KEY,DONGLE在中国被音译为“狗”,主要是防止软件被盗用RPM和WEB SERVER之间的鉴权如果在安装时选择安装REMOTE PERFORMANCE MONITOR SERVER,LOADRUNNER会弹出一个要求输入用户名和密码的对话框, REMOTE PERFORMANCE MONITOR SERVER是一个远程监视场景的服务器,为测试人员提供WEB化的场景页面,用于实现多台及其通过浏览器同时在线监视场景.这里设定用户名和口令的目的主要是为了REMOTE PERFORMANCE MONITOR(RPM)和运行了IIS的WEB SERVER之间进行鉴权.在RPM安装完毕之后,只有在LOADRUNNER CONTROLLER的RPM用户配置对话框中输入指定的用户名和口令,系统才能允许进行远程监控.设定LOADRUNNER GENERATOR如何登陆到CONTROLLERLOADRUNNER提供了两种方式让LOAD GENERATOR的虚拟用户登陆到CONTROLLER,n ALLOW VIRTUALUSERS TO RUN ON THIS MACHINE WITHOUT USER LOGINn MANUAL LOG IN TO THE LOAD GENERATOR MACHINE三、使用VITUAL USER GENERATOR录制开发脚本LOADRUNNER脚本的开发过程一般需要以下几个过程使用LOADRUNNER的VIRTUAL USER GENERATOR录制基本的测试脚本;根据系统需求编辑测试脚本,看能否通过,在单机模式下运行脚本看能否通过,1.选择协议要想正确的选择LOADRUNNER的脚本协议,首先要从LOADRNNER的工作原理上深入理解协议的作用和意义。
Loadrunner的工作总结
Loadrunner的工作总结
刚开始入门用Loadrunner的时候就只会用Web(HTTP/HTML)协议录制网页的,但是公司的很多程序都非得搞个C/S程序端,美名其曰:高级,工作总结1——Loadrunner。
这样我不得不开始尝试录制CS程序的通信。
记得第一次的时候我问项目组用啥协议实现的程序,他们来句不清楚,是调用别人的控件,我很无语,有这么搞开发的吗?于是我就尝试各种协议混合录制了,发现COM/DCOM和Web(HTTP/HTML)可以录制到客户端的行为,于是我用这另个协议创建多协议脚本,然后参数关联化,搞定本个项目的测试了,呵呵~~~小小喜悦一下,毕竟在啥都没的前提下,连个咨询的人都没的情况下,我只能自己摸索,自己给自己鼓励了,工作总结《工作总结1——Loadrunner》。
第二次就是现在从事的项目的,开发组真的很会共享,共享的连哪里来的都不知道了,用的啥都不清楚,我只好问里面比如上传附件用的是啥协议,他来句:应该是FTP协议啊,我用这个脚本一录制,还好他没说错,可以实行,不然我真想揍人,哪有开发组啥都不提供就叫人测试的啊~~我又不是神仙,一看就懂,更何况我还是个新人呢。
这次用的是FTP和Web(HTTP/HTML)协议多协议脚本录制的,成功~~呵呵
每天有一点小进步就很开心~~。
LoadRunnerLoadRunner是MI公司的自动化的Windows 95/98,Windows NT和UNIX系统的client/server性能测试工具。
它施压于你的整个的应用程序,来隔离和识别潜在的客户端、网络、服务器瓶颈。
它使你能在受控的和高峰负载条件下测试你的系统。
通过运行分布在网络上的成千上万的虚拟用户(取代真实用户)来产生负载,一台机器上可以运行许多虚拟用户。
使用最小的硬件资源,这些虚拟用户提供一致的、可重复的、可度量的负载来像真实用户那样操作你的应用程序。
它的深入的报告和图表提供给你评价应用程序性能的信息。
LoadRunner模拟多用户并发环境进行负载测试,精确度量、监测和分析系统性能与功能。
它的在线监测器使你能在测试执行期间调校你的系统。
当性能delay发生时,LoadRunner检查网络或客户端delay、CPU性能、I/O delay、数据库locking和数据库服务器的其他问题。
LoadRunner监测网络和服务器资源来帮助你提高性能。
完整的应用程序性能测试方案必须:测试一个结合多种软件应用程序和硬件平台的系统对给定的应用程序决定一个适宜的SERVER在必需的客户端软件开发之前测试SERVER模拟多用户和单一服务器应用程序交互的环境在几十个、几百个甚至成千上万个潜在用户的负载下测试一个应用程序AUT The application under testVuser A virtual user—a LoadRunner-created user that emulates a human userLoad Generator machine The workstation used to host the Loadrunner Vusers Controller machine The workstation used to host the LoadRunner ControllerVuser Group A collection of Vusers with common characteristics, such as the machine on whichthey run, or the client that they useLoadRunnerWINDOWS最小系统配置:Standalone installation:在一个单用户计算机上安装LoadRunner CH2Network installation:在一个网络驱动器上安装LoadRunner,对具有该网络驱动器访问权限的所有用户可用CH3在一个网络上安装LoadRunner 后,用户可以使用workstationinstallation 来使用网络上的LoadRunner 共享版本。
LoadRunner知识总结一、需求分析1.正规:分析需求,需求方面的测试(功能有无重复,有没有遗漏,有没有二义性,有没有不同的),提取需求点,2.不正规:产品,项目。
绿色通道?1)经常调用的模块;2)关键业务;3)业务量大的模块;4)问下开发,测试组长,自己模拟客户习惯a)自己画出功能结构图(上网查,询问需求人员,然后把思路写出来,根据自己的理解画出来)b)看实际效果c)和他们确认是不是这样的二、指标提取1.并发数:如果没有要求,根据业务量和时间段去算。
业务量可以问一下客户,也可以问问开发或者凭自己的经验,时间段可以询问客户,或者查看系统日志,但是前提是有系统日志。
如果什么都没有的话可以用2,8原则。
2.响应时间:响应时间不包括思考时间,仅仅是服务器的响应时间,一般遵循2,5,8,10的原则,并且大多数情况下要求响应时间在5S之内。
3.业务成功率:一般要求100%4.系统资源占用:包括CPU,内存,网络,硬盘,其它。
一般都要在75%以下,这是经验值。
但是网络带宽一般是50%以下。
三、建立模型深入分析系统业务流程,考虑以下几个方面:1.有没有约束条件2.业务逻辑方面:系统中对数据有没有唯一性3.系统中有没有消耗性数据(用完数据就丢了)4.有没有需要特殊说明的5.在注释中写出来需要做关联,文本检查点和集合点的地方四、设计用例约束条件,操作步骤,期望值,测试项。
测试数据,如果是参数化了的,写一个数据,后面括号,参数化。
尽量在这里考虑全五、录制脚本录制脚本的时候最重要的是选择协议数据库ODBC选择协议出错代码为空的首先知道什么协议(问程序员),划分Action编译,回放脚本LR可以随机链接其他页面,做参数化即可六、优化脚本做完以后进行语法检查进行回放——看是否需要参数化和关联系统对客户端输入的东西有唯一性要求:做参数化(Log中的参数替换勾上,看参数化是否正确)服务器给客户端的东西不同:做关联文本检查点成功标志位1)树视图下界面上面,右键添加文本检查点2)Server下找相应的字段3)到界面的源代码下去找调优比较测试事务点:分析结果的时候可以确定响应的结果,确定代码在哪一块有问题,比Action更细化,反应响应时间。
LoadRunner检查点使用小结第一篇:LoadRunner检查点使用小结LR中检查点有两种:图片和文字。
常用检查点函数如下:1)web_find()函数用于从 HTML 页中搜索指定的文本字符串;2)web_reg_find()函数注册一个请求,以在下一个操作函数(如web_url)检索到的HTML网页上搜索指定的文本字符串;3)web_image_check()函数用于从HTML页面中查找指定的图片;4)web_global_verfication()属于注册函数,注册一个在web页面中搜索文本字符串的请求,与web_reg_find只在下一个Action函数中执行搜索不同的是它在之后所有的Action类函数中执行搜索指定的文本字符串;下面分别介绍以上函数的用法:1、web_find()函数参数举例:web_find(“web_find”,“RighOf=a”,“LeftOf=b”,“What= name”,LAST);参数解释:“web_find”定义该查找函数的名称;“LeftOf”和“RighOf=”用来定义查找字符的左右边界;“What=”定义查找内容;例如上述参数举例中的意思就是在页面中查找左边界为b,右边界为a,内容为name的信息;使用该函数注意事项:该函数是在查找页面中的内容,所以要放在要查找的内容的后面;该函数只能在基于HTML模式录制的脚本中进行查找注意事项:使用该函数时,要在Vuser->Run-Tme Settings中更改下设置勾选Enable Image and text check系统默认是不勾选该选项的。
2、web_reg_find()函数参数举例:web_reg_find(“Search=Body”,“SaveCount=ddd”,“T est=aaa ”,LAST);参数解释:Search用来定义查找范围,SaveCount定义查找计数变量名称,该参数可以记录在缓存中查找内容出现的次数,可以使用该值,来判断要查找的内容是否被找到;例如上述参数举例中的意思就是Body中查找内容为aaa的信息,并将出现次数记录在变量ddd中;【代码一:web_reg_find(“T ext=Payment Details”,LAST);代码思路:1.“Payment Details” 为你要检查的文本;2.脚本执行到此处,若在页面上找到了这几个字符串,那脚本继续执行下去;若没有找到,脚本将在此报错并且结束。
Loadrunner学习经验目录使用LoadRunner测试时需要注意以下环节的操作: (1)LoadRunner在使用时遇到的问题及解决方法 (2)如何在Controller中添加系统资源检测 (6)LoadRunner监控Windows/Unix系统资源需要做两件事情: (6)监控linux (8)unix/linux的计数器 (12)loadrunner回放脚本常见问题及解决方法 (14)lr_eval_string()函数以及LR中参数、变量的简单使用 (19)给出一部分常用的LoadRunner函数,供大家参考。
(20)使用LoadRunner测试时需要注意以下环节的操作:1、测试服务器再承受压力时,要尽量避免网络造成的瓶颈问题,即服务端和客户端一定要再同一局域网内,否则网络因素可能会造成性能测试的瓶颈,无法发现真正的瓶颈。
2、再性能测试脚本中要注意检查点的设置,否则将难以发现脚本本身的错误。
3、设置参数化和关联是性能测试脚本能顺利回放的关键,所以要对录制好的脚本进行完善。
4、录制脚本时通常会包括一些思考时间(Think Time),因此再回放脚本时,应注意再设置中设置忽略思考时间,否则会影响测试数据的准确性。
对一个系统用同一策略进行两次测试时,忽略思考时间将使测试结果更准确。
5、尽量为每个页面设置一个事务,否则不知哪个页面最慢。
6、运行性能测试脚本时应该关闭日志功能,再调试脚本时在打开。
7、性能测试前的数据准备很重要,如:系统数据库中存在60和60000条数据,测试结果肯定是不一样的,应尽量按照真实环境的数据量进行测试。
8、在性能测试时每个用户登陆的用户名和密码应尽量不同。
9、录制时若录制不到信息,可查看ie局域网设置中,是否去掉了“自动检测网络”一项。
10、通用Vuser函数和特定于协议的函数,他们二者共同构成了LR API,并使Vuser能直接与服务器通信。
录制后的脚本具有跨平台特性。
LoadRunner学习小结今年十月份我到北京跟张坤学习性能测试知识,共花了三个星期学习LoadRunner。
以下是我的学习小结。
一.什么是LoadRunnerLoadRunner是一种预测系统行为和性能的工业标准级负载测试工具。
通过以模拟多个用户实施并发负载测试及实时性能检测的方式来确认和查找问题,能对整个企业架构进行测试。
二.LoadRunner的优点1.轻松创建虚拟用户:通过记录下业务流程转为测试脚本,在机器上产生多个用户访问,减少负载测试需要的硬件和人力资源。
2.创建真实的负载:可以通过Controller设定负载方案,如定义用户在什么时候访问系统以产生负载,所有用户同时执行一个动作来模拟峰值负载情况等。
3.实时监测器:可以实时显示交易性能数据(如响应时间)和其他系统组件如数据库,网络等的实时性能。
4.分析结果以精确定位问题所在:LoadRunner能收集汇总所有测试数据,提供高级的分析和报告工具。
三.LoadRunner的安装与使用1.安装过程详见上传的LoadRunner使用手册,在此不再详细介绍。
2.具体使用:点击File新建录制文件,也可以点击下面的NEW快捷键进行新建。
使用File新建,会弹出协议选择窗口,选择新的单协议脚本(New Single Protocol Script)的Web(HTTP/HTML)项,确定即可(选择Web项是因为我们测试的是Web应用)。
接着会弹出开始录制的设置项,需要写入录入系统的地址,点击确定后就会根据录入地址展现系统页面,开始录制脚本,出现小工具条:第一个按钮为录制键第二个为回放脚本键第三个为停止录制键第四个为暂停录制键第五个为编译脚本键第六个为创建新的Action键。
LR的录制脚本分为三个部分,vuser_init、vuser_end 和Action。
脚本循环执行时,只执行一次vuser_init和vuser_end,而多次循环Action 部分。
LoadRunner11测试结果分析之我见LoadRunner生成测试结果并不代表着这次测试结果的结束,相反,这次测试结果的重头戏才刚刚开始。
如何对测试结果进行分析,关系着这次测试的成功与否。
网上关于LoadRunner测试结果如何分析的介绍相当匮乏,在总结他人的观点和自己的实验体会基础上来介绍如何进行LoadRunner测试结果分析。
1. LoadRunner测试结果分析的第一步应该是查看分析综述(Analysis Summary),其包括统计综述(Statistics Summary)、事务综述(Transaction Summary)、HTTP 响应综述(HTTP Responses Summary)三部分。
在统计综述中查看Total Errors的数量,HTTP 响应综述中查看HTTP 404数量,若数值相对较大(HTTP 404则相对于HTTP 200),则说明系统测试中出错较多,系统系能有问题;另外查看事务的平均响应时间和其90%的事务平均响应时间,若时间过长,超过测试计划中的要求值,则说明系统的性能不满足我们的要求。
2. 第二步对LoadRunner测试结果图进行分析,首先对事务综述(Transaction Summary)进行分析,该图可以直观地看出在测试时间内事务的成功与失败情况,所以比第一步更容易判断出被测系统运行是否正常。
3. 接着分析事务平均响应时间(Average Transaciton Response Time),若事务平均响应时间曲线趋高,则说明被测系统处理事务的速度开始逐渐变慢,即被测系统随着运行时间的变化,整体性能不断下降。
当系统性能存在问题时,该曲线的走向一般表现为开始缓慢上升,然后趋于平稳,最后缓慢下降。
原因是:被测系统处理事务能力下降,事务平均响应时间变长,在曲线上表现为缓慢上升;而并发事务达到一定数量时,被测系统无法处理多余的事务,此时曲线变现为趋于平稳;当一段时间后,事务不断被处理,其数量减少,在曲线上表现为下降。
如果被测系统没有等待机制,那么事务响应时间会越来越长,最后系统崩溃。
4. 再分析每秒通过事务数(Transactions per Second/TPS),该曲线表示被测系统在运行的任意时刻,每个事务通过、失败的情况,其是考查系统性能的一个重要参数。
若随着压力的增加,曲线如果开始变化缓慢或有平稳的趋势,则有可能是服务器开始出现瓶颈。
[5]. 分析每秒通过事务总数(Total Transactions per Second),该曲线显示在任意时刻被测系统通过的事务总数、失败的事务总数。
该曲线走向和TPS曲线走向一致。
[6]. 事务性能摘要(Transaction Performance Sunmmary)该曲线表示被测系统中所有事务的最小、最大和平均事务响应时间。
[7]. 事务在负载情况下的响应时间(Transaction Response Time Under Load),该曲线表示在不同数量的虚拟用户情况下的事务响应时间情况。
该图对分析具有渐变负载的测试场景比较有用。
[8]. 事务响应时间(百分比)(Transaction Response Time(Percentile)),该曲线可以容易地分析出在给定的响应时间范围内事务量的百分比重。
[9]. 事务响应时间(分布)(Transaction Response Time(Distribution)),该图可以容易地分析出在给定响应时间范围内的事务量情况。
其实,若并不是十分详细地分析测试结果,第4步与第5步选其一分析,第6步、第7步、第8步为可选项,因为在第1步就在一定程度上分析了,而第9步又与第8步功能相识。
LoadRunner生成测试结果图在很大的程度上具有一定的重复性,只不过是在不同情况下的具体显示。
上述测试过程的重点在于事务,而LoadRunner生成的测试结果图并不局限于事务上,其中还有是关于Vusers、Errors、Web Resources、Web Page diagnostics 的测试图。
1. 对于Vusers的测试图有3种:Running Vusers、Vusers Summary、Rendezvous,其中Running Vusers是关于虚拟用户加压、施压、减压的情况图;Vusers Summary是用户运行结果的综述图;Rendezvous是虚拟用户的集合点情况图。
这三种图单独分析没有多大的价值,一般都是和其他图合并分析。
2. 对于Errors的分析,若是在上述测试中发现被测系统运行中有很多错误,则Errors测试结果有分析的必要,否则,就不必发费时间在Errors上了。
其主要包括Error Statistics、Error Statistics(by description)、Errors per Second(by description)、Errors per Second 、Total Errorss per Second,Error Statistics是带有错误代码编号的饼状图,Error Statistics(by description)不仅有错误代码编号,而且带有错误消息,Errors per Second是每秒错误数的曲线图,Errors per Second 与Errors per Second(by description)的区别也是在于是否带有错误消息。
Total Errorss per Second是被测系统每秒错误总数的曲线图。
若要对系统进行错误分析,则Error Statistics与Error Statistics(by description)、Errors per Second(by description)与Errors per Second择其一即可,不过带有错误描述的图更加具体。
3. Web Resources测试主要是对Web服务器性能的分析。
3.1每秒点击次数(Hits per Second)是Vusers每秒向Web服务器提交的HTTP 请求数。
查看其曲线情况可以判断被测系统是否稳定,曲线呈下降趋势表明Web 服务器的响应速度在变慢,当然其原因可能是服务器瓶颈问题,但是也有可能是Vusers数量减少,访问服务器的请求减少。
点击数:不是根据用户的鼠标点击次数计算,而是根据客户端向服务器发起的请求次数计算。
例如:若一个页面里包含10张图片,那么在访问该页面时,鼠标仅点击1次,但是服务器收到的请求数却为1+10(每张图片都会向服务器发出请求)。
此时其点击次数为11。
3.2吞吐量(Throughput)度量单位是字节,另外也有兆字节,其是度量服务器性能的重要指标,表示服务器在任意时间的吞吐能力,即任意时间服务器发送给Vusers的流量。
吞吐率=吞吐量/测试时间,单位时间里服务器发送给Vusers的流量。
点击率=吞吐量/测试时间,单位时间里Vusers发送给服务器的HTTP请求数。
[3.3]状态代码概要(HTTP Status Code Summary)表示从服务器返回的带有HTTP状态的数量分布。
其HTTP状态有HTTP 200、HTTP 302、HTTP404等。
该图可以容易看出HTTP响应状况。
[3.4] 每秒HTTP响应数(HTTP Responses per Second)表示每秒从服务器返回的HTTP状态的曲线图。
其和HTTP Status Code Summary不同在于后者是总体数量分布,而它是分布在时间段上的平均分布状况。
[3.5] 每秒重试次数(Retries per Second)表示单位时间内服务器尝试的连接次数。
服务器重试连接的情况:初始连接未经授权、要求代理服务器身份验证、服务器关闭了初始连接、初始连接无法连接到服务器、服务器最初无法解析负载生成器的IP地址。
重试次数概要(Retries Summary)是表示服务器重试连接次数量的饼图。
[3.6] 连接数(Connections)显示任意时间点的TCP/IP连接数。
借助此图,分析应该何时添加其他连接。
每秒连接数(Connections Per Second)显示单位时间里新建或关闭的TCP/IP连接数。
该图呈下降趋势,就表明每秒连接数减少,也即服务器性能下降。
对于页面资源的测试结,3.1步和3.2步应该分析,3.3步和3.4步在分析综述(Analysis Summary)中已经做了一定的分析,没有特定需求可以不做分析,若是想了解在什么时间出现何种HTTP(如错误HTTP 404),则要分析3.4步。
至于3.5步可以了解在何时进行了重新连接,是什么原因导致。
3.6步分析恰当的时间添加连接。
前面分析的Web Resource(网络资源)的测试情况,其主要关注的是服务器性能,而系统本身和环境都有可能存在问题,页面诊断(Web Page Diagnostics)主要就是关注这方面的问题。
页面诊断可以很好地定位环境问题,如客户端问题、网络问题等,也可以很好的分析系统本身的问题,如网页问题。
1.Web Page Diagnostics (网页诊断)对测试过程中所有的页面进行一个信息汇总,可以很容易地观察出哪个页面下载耗时,然后选择该页面得其页面分解图,分析耗时原因。
Web Page Diagnostics是一个汇总图,选择要分析的页面,可得到其4张图:Download Time、Component(Over Time)、Download Time(Over Time)、Time To First Buffer(Over Time)。
Download Time分析页面不同组件在不同阶段的所需时间,其阶段主要包括:DNS Resolution:DNS域名解析所需的时间;Connect:与Web服务器建立初始连接所需的时间;SSL Handshaking:建立SSL连接所用的时间;FTP Authentication:认证客户端所需的时间;First Buffer:初始HTTP请求至WEB服务器响应成功所需的时间;Receive Time:浏览器从服务器接受字节并完成下载所经时间;Client Time:因思考时间或其它客户端问题导致的请求发生延迟所经时间;Error:从发出HTTP请求到接收到错误消息所需的时间。
这样就可以分析出时间花费在哪里,进而定位问题。
Component(Over Time)页面上不同组件在不同时间的平均下载时间曲线图。
Download Time(Over Time)不同组件在不同时间的平均下载时间面积图。
Time To First Buffer(Over Time)不同组件不同时间第一次缓冲时间面积图。