LR性能测试应用

时间 2019-12-01

原文原文链接

上半个月，因为工做和上课两边跑，几乎没有属于本身的时间去作本身想作的事，在没有加班的一天晚上，我忽然冲动地跑到图书馆借了一本书《LR性能测试应用》——姜艳。html

我总喜欢看那些陈旧的书，由于在咱们忙碌的生活中，它又让我不经意间拾起了那一段记忆。一本好书，能够改变一我的的一辈子，是由于从中使用我获得知识的渴望和追求，不断地总结，不断地成长。。。。。。web

《LR性能测试应用》我花了半个月看这确是一本好书，书中内容分为三部分，“基础篇”、“提升篇”、“实战篇”。看完了这本书我最大的收获是，有了一个明确的LR性能测试思想和思路。在“基础篇”中，认识到一些曾经一直模糊的性能测试概念，以及LR的工做原理；算法

在“提升篇”中，从LR建立脚本，对脚本的优化（包括设置事务、参数化、关联、IP欺骗）以及对脚本中出错的处理、调优等，再从建立场景中，设置场景的策略方法，集合点的策略设置，还有对不一样服务器的监控分配和负载均匀等，最后对Analysis分析图表说明、结果总结。sql

1、提升篇：数据库

性能测试的核心原来，其实就是，经过将生产时的工做量应用于部署系统来衡量系统性能和最终用户体验。浏览器

对性能测试的一些模糊概念，一直没有认真研究弄懂区分过，关于压力测试和负载测试有什么区别尚未弄懂的，以下是个人博客：http://www.cnblogs.com/luihengk/archive/2012/09/20/2695366.html缓存

在这里我只强调几个概念：服务器

并发用户数：关于并发用户数，有两种常见的错误理解：一种是把并发用户数量理解为使用系统的所有用户的数量，理由是这些用户可能同时使用该系统；另外一种相对接近的观点是把用户在线数量理解为并发用户数量。实际上，在线用户不必定会和其余用户发生并发，例如正在浏览网页信息的用户，对服务器没有任何影响的。正确的理解是在同一时刻与服务器进行交互的在线用户数量。对服务器而言，是否并发的关键是看用户的操做是否对服务器产生了影响。这种交互能够是单向的数据传送，也能够是双向的数据传送。网络

在实战经验中，通常的并发用户数量=在线用户数*（5%～20%）；并发

响应时间：是指从客户端发送一个请求开始计时，到客户端接收到从服务器端返回的响应结果结束计时所经历的时间，通常状况下，响应时间是由网络传输时间。服务器处理时间和浏览器显示时间三部分组成。

（TTLB，即为请求响应时间，意思是从发送一个请求开始，到客户端收到最后一个字节的响应为止所耗费的时间。）

吞吐量：就是吞吐量/传输时间，用来指单位时间内网络上传输的数据量，也能够指单位时间内处理的客户端请求数量。

TPS：每秒钟系统可以处理的交易或事务的数量。

点击率：指每秒钟用户向Web服务器提交的HTTP请求数。

（注意：这里的点击不是指用鼠标的一次单击操做，困为在一次单击操做中，客户端可能向服务器发出多个HTTP请求）

整体上，LR的性能测试的工做流程大概以下：

一、建立脚本(Virtual User Generator)

在建立脚本的时候须要注意的是，要选择与应用程序相对应的正确的协议，否则在浏览器录制会没有内容，若是不知道应用程序是基于哪一种脚本语言协议的，能够经过一些工具进行捕获数据包，进而分析，如网络捉包软件OmniPeek4.1。

在进行性能测试时，大部分对web性能测试，选择“Web(HTTP/HTML)”协议便可，但录制完脚本后，回放脚本中有时会发生中断或者中止的状况，查看错误时，若是没法找到SOAP文档字样时，就须要考虑更换脚本录制协议了。一般首先考虑更换Web Services协议，再录制脚本。

在开始录制的时候，须要对运行环境进行设置

如图：

设置好环境后，必需要对录制的脚本进行优化

例如：

脚本：

//首页登陆退出录制

Action()

{

web_url("WebTours",

"URL=http://127.0.0.1:1080/WebTours/",

"Resource=0",

"RecContentType=text/html",

"Referer=",

"Snapshot=t1.inf",

"Mode=HTML",

LAST);

lr_think_time(13);//思考时间，在录制过程当中能够忽略

web_reg_find("Text=Welcome",

LAST); //设置检查点

lr_start_transaction("login"); //设置开始事务

web_reg_save_param("username", //设置关联

"LB=Thank you, <b>",

"RB=</b>, for registering and welcome to the Web Tours family.",

"Ord=ALL",

"Search=NoResource",

LAST);

web_submit_form("login.pl",

"Snapshot=t2.inf",

ITEMDATA,

"Name=username", "Value={username}", ENDITEM, //设置参数化

"Name=password", "Value={password}", ENDITEM, //

"Name=login.x", "Value=59", ENDITEM,

"Name=login.y", "Value=10", ENDITEM,

LAST);

lr_end_transaction("login", LR_AUTO);//设置结束事务

lr_rendezvous("login"); //设置集合点

lr_think_time(4);

web_image("SignOff Button",

"Alt=SignOff Button",

"Snapshot=t3.inf",

LAST);

return 0;

}

在咱们录制了脚本后，能够完善脚本呢？

一、录制完脚本后，第一件事情就是回放脚本，若是没有报错，能够在脚本中插入事务，也能够在录制的时候插入事务，建议采用在脚本的录制过程当中插入事务的方法，这样就不至于遗漏程序中应插入事务的操做了。

二、插入集合点，须要明确的是，须要在并发哪一个业务任务操做前插入集合点，如：在一个登陆操做或者查询操做插入，输入集合点的名字要顾名思义。（注意：集合点只能在Action中插入，不能在vuser_init 或 vuser_end中插入）

三、插入注释，“Insert——Comment”。

四、插入LR API经常使用函数。

如： web_custom_request();

Web_image();

Web_link();

五、脚本参数化，必须选定参数化的格式类型，如是日期型、仍是导入数据库参数化。

参数化设置以下操做：

用参数替换脚本中的常量；
为参数设置属性和数据源；

须要注意事项：在参数化的过程当中，只有函数中的参数能被参数化，并且也不是全部的函数中的参数都能参数化，如Lrd_stmt只能参数化mpcText；参数化只能够用于一个函数中的参量，但不能用参数表示非函数参数的字符串，关联函数是不能参数化的。

六、脚本关联(手动关联)，操做步骤以下：

使用相同的业务流程与数据，录制两份脚本；
使用WinDiff工具协助找出须要关联的数据；
使用web_reg_save_param函数手动创建关联；
将脚本中有用到关联的数据，以参数取代；

在这里必须说明：在Recording Log（单协议）或是 Generation Log（多重协议）中找到不能肯定是否须要关联的数据时，这时要确认数据是否为从服务器端传送过来的。首先能够检查数据的标头，从标头的Receiving response能够知道数据是不是从服务器端传送到客户端的。假如此数据第一次出现是在Sending request中，则表示此数据是由客户端产生，不须要作关联，可是有可能须要作Parameterized（参数化）。

二、建立场景（Controller）

在建立场景的设置中，就须要对用户的需求来设置场景了，能够按方案计划实施（Schedule by Scenario），也能够案组计划实施(Schedule by Group)，而后打开“Scenario Start”设置方案开始策略。

配置方案：在配置方案时，须要对运行时环境的设置“Tools——Options”

方案模式的选择有两种状况：一种是百分比方案模式，一种是面向目标的方案模式。若是用户需求比较明确，能够选择面向目标的方案模式，设置指望值。

注意：在设置方案计划中，持续时间设置将覆盖Vuser迭代设置。这意味着，若是将持续时间设置为5分钟，那么Vuser将继续在5分钟时间内运行尽量多的迭代，即便运行时设置仅指定一次迭代。

三、结果分析(Analysis)

当场景运行结束后，能够经过Analysis采集到数据信息（主要是图表），咱们能够根据以一几种方式分析这些数据：

一、查看Vuser Log文件，这些文件包括了场景运行过程当中每一个用户的跟踪数据，Vuser Log 文件通常放在脚本目录中；

二、在控制台中输出窗口查看场景的执行过程信息；

三、使用Aanalysis模块分析执行结果图表；

四、使用直接生成的图表查看原始数据——Graph Data 或者 Raw Data ；

五、让LR自动生成HTML或Word格式的测试报告，经过报告进行分析。

在这里说下，Analysis摘要报告包含一个事务百分比列，默认为90%的事务响应时间（90%是一个统计响应时间的参数，代表该事务全部的运行次数中，90%的次数落在这个响应时间内），此数值如没有特殊要求不用改动。

2、提升篇

设置关联：在脚本中设置手动关联一贯是个难题，有些关联的地方是有多处，前面的关联若是没有执行经过，执行将中止验证脚本的正确性，后面须要作关联的部分没法被扫描出来。

在关联中，如何打印出参数值？

Lr_output_message(“valueCaptured=%s”,lr_eval_string(“{ParameterName}”));

IP欺骗配置方法：IP Spoofer 应该在链接负载生成器以前启用。同时，各个负载生成器机器必须使用固定的IP，不能使用动态IP（即DHCP）。

第一次运行IP Wizard须要选择第一项“Create new settings”；若是之前运行过IP Wizard，能够选择第二项“Load previous setting from file”,选择之前保存的文件；第三项用于使用“IP Spoofer”进行测试完成后，释放IP的过程，由于该机器会点用大量的IP资源，可能会致使其余机器没有IP可用，使用该项，可使系统恢复到原来的情况。

当咱们成功配置了IP Spoofer后，须要从新启动计算机，虚拟IP设置才成功，能够在“开始->运行->”输入cmd ，在窗口输入“ipconfig/all”命令查看已生效的全部IP

为了使用LR配置的虚拟IP，还须要在控制台中对场景进行正确的设置，选择“Scenario > Enable IP Spoofer”，设置容许使用IP欺骗。

对Oracle监控配置：安装好Oracle后，须要在Oracle的客户端中配置服务名，步骤以下图：

一、启动“Net Configuration Assistant”界面，选择：

二、下一步，选择“添加”

三、下一步，填写数据库名：

四、下一步，选择协议：

六、下一步，填写机器的IP：

七、最后一步进行配置测试：

若测试配置链接未成功，则须要 ”更改口令”，由于默认值为系统管理员的用户名和口令（都是“system”）,可使用事先已配置好的用户登陆，而后用sqlplus链接一下，尝试用户登陆，看是否能够链接成功。

最后，在LR的场景监控中，添加Oracle计数器，实行监控便可。

HTTP服务器状态码：

消息1XX：该类状态代码用于表示临时响应，临时响应状态行以及可选标题组合。

消息2XX：该类状态代码表示客户端请求被成功接收、理解或接受。

HTTP 200 OK 请求成功；

HTTP 201 Created 请求完成；

HTTP 204 No Content 无内容；

消息3XX：表示重定向，该类状态码用户代理要想完成请求，还须要发出进一步的操做。这些操做只有当后跟的请求是GET或者HEAD时，才可由用户代理实现，而不用现用户进行交互。用户代理永远也不要对请求进行5次以上的重定向操做，这样可能致使无限循环。

消息4XX：表示客户端错误，如时客户端在收到此类状态代码时，请求尚未完成，它应当当即终止向服务器发送数据。

HTTP 400 Bad Request 非法请求；

HTTP 401 Unauthorized 未受权；

HTTP 403 Forbidden 禁止；

HTTP 404 Not Found 没有找到；

消息5XX：表示服务器错误，不能继续执行请求

HTTP 500 Internal Server Error 服务器内部错误

HTTP 501 Not Implementec 未实现

HTTP 502 Bad Gateway 非法网关

HTTP 503 Service Unavailable 服务不可用

LR默认计数器：

性能计数器一般用来衡量被测系统当前的情况和进行性能测试结果分析。如面对经常使用的计数器值进行分析：

1）、与进程Process相关

%process Time ：被处理器消耗的处理器时间数量。多数用于监测服务器（如：数据库服务器或应用服务器），该值通常不要超过85%；

Page Faults/sec ：处理器处理错误页的综合速率，错误页数/秒，表示当处理器请求一个不在其工做集（在物理内存中的空间）内的代码或数据时出现的页错误数=软错误数（在物理内存中访问出错）+硬错误（在磁盘中访问出错）数；

（注意：处理器在有大量软错误下仍然能够继续操做，而出现硬错误时，则能够致使明显的延迟）

Pages Input/sec ：指为解决页错误时而每秒从磁盘上读取的页数，越少越好；

Pages Reads/sec ：指为解析硬错误而每秒读取磁盘的次数，若是该值比率持续保持为5，则表示可能内存不足；

Work set ：处理线程最近使用的内存页，反映了每个进程使用的内存页的数量，该值越低越好；

Private Bytes ：此进程所分配的没法与其余进程共享的当前字节数量。若是系统性能随着时间而下降，它是检测内存泄露的最佳观察指示器；

2）、与处理器Processor相关

%Processor Time ：若是该值持续超过95%，代表是CPU瓶颈；

Processor Queue Length ：指处理队列中的线程数，显示在由Web服务器全部处理器共享的队列中等待执行的线程数，若是该值持续大于2，则表示处理器瓶颈了；

%User Time ：非内核操做耗费的CPU时间。通常来讲吧，若是系统中使用了大量的算法或者复杂的计算，该值是比较大的；

%Privileged Time ：CPU内核时间是在特权模式下处理线程执行代码所花的时间%，该值越低越好；

%DPC Time CPU消耗在网络处理上的时间，该值越低越好（与网络有关）；

3）、与内存Memory相关

Available Mbytes ：可用物理内存数，通常要大于机器物理内存的1/2个字节；

Pages/sec ：代表因为硬件页面错误而从磁盘读取出来的页面数，或是因为页面错误而写入磁盘以释放工做集空间的页面数；

Cache Bytes ：文件系统缓存，默认状况下是50%的可用物理内存；

4）、与物理磁盘Physical Disk相关

%Disk Time ：所选磁盘驱动器忙于为读或写请求提供服务所用的时间的%；

%Aerage Disk Queue Length ：指读取和写入请求的平均数，该值不该超过磁盘数的1.5～2倍；

Disk Queue Length 指标显示磁盘中未完成的请求数量，若是队列长度始终大于3，则表示磁盘或者内存问题，须要进一步分析；

Current Disk Queue Length指标的值应该平均小于2，若是%Disk Time 比较大，而该值又大于2，此时是磁盘瓶颈，须要提升系统磁盘处理性能；

5）、与网络接口相关

Bytes Total/sec ：为发送和接收字节的速率，能够判断网络链接速度是不是瓶颈；

Current Bandwidth ：指以位/每秒估计的网络接口的当前带宽；

Output Queue Length ：为输出数据队列（数据包）的长度。若是该值大于2，则会出现延缓现象；

6）、SQL Server 、Oracle 、IIS 、Tuxedo 、weblogic 等计数器的分析略；

LR计数器监控值我的分析思路：

判断处理器CPU瓶颈：先看Processor Queue Length 是否大于2，再看%Processor Time 一个或多个处理器的相应数值是否持续超过90%，若是以上状况都出现，则表示此测试的负载对于目前的硬件过于沉重了，处理器有多是瓶颈，此时还须要监控%Interrupt Time 计数器，若是该计数器持续大于15%，而处理器使用率也持续超过90%，就能够判定处理器负荷太重，没法知足业务增加的须要，处理器是系统瓶颈点。

判断内存Memery瓶颈：先看 Available Mbytes的值是否持续很小来判断是否有存在严重内存泄露的迹象，再看Page Read/sec的值，若是Pages/sec和Page Faults/sec的值持续很高，这时判断多是内存有问题，此时再检查Pages Read/sec的值是否超过5，若是是大于5，则能够肯定是内存存在问题了。

判断磁盘Disk瓶颈：先看Disk Time指标和Avg.Disk Queue Length 指标的值都很高，而Page Reads/sec页面读取操做速率很低，则能够肯定是磁盘存在问题；再者，查看Disk Queue Length 值始终大于3，Current Disk Queue Length 也大于2，则表示磁盘存在问题了。

LR部分函数中文翻译：http://www.cnblogs.com/luihengk/

3、实战篇

一、如何分析性能需求指标呢？

1）、并发用户指标：并发用户数>=？？

2）、系统响应时间指标：页面响应时间<=？？

3）、系统稳定性指标：系统有效工做时间要求>=？？%

Web服务持续稳定工做时间>=？？天或（小时）

4）、系统吞吐量指标：吞吐量？？如：完成业务状况（数据库容量）>=？？万笔交易数

5）、业务处理能力性能指标：每笔业务的响应时间<=？？

登陆要求响应时间<=？？

业务处理能力（即每秒请求数）>=？？

TPS（每秒交易数）>=？？

6）、风险需求：容灾需求中的性能指标，如当并发用户数达到多少、天天完成最大的交易数等等时系统会崩溃的状况。

二、估算过程参考的行业标准？

1）、并发强度指标：使用80/20法则肯定，即并发用户峰值数按日高峰访问量的80%计算，并发用户最小值按照日均访问量的20%计算。

2）、日高峰业务处理能力：使用80/20法则推算，即假设80%的工做在20%的工做时间内完成。在工做时间内，80%的业务是在整个工做日的20%时间内完成，此时的业务量按照天天可能发生的最大交易量乘以80%来计算，工做时间按照正常时间8小时的20来进行计算。

3）、高峰日的业务处理能力：使用80/20法则推算，即假设每一年80%的业务集中在20%的时间内完成。

4）、容灾处理能力：业务处理总量/2

LR注意事项：

测试服务器在承受压力时，要尽可能避免网络形成的瓶颈问题，即服务器端和客户端必定要同一个局域网内，不然网络因素可能会成为性能测试的瓶颈；
性能测试脚本中要注意检查点的设置，不然将难以发现脚本自己的错误；
须要对脚本的参数化设置和关联设置；
设置在回放脚本时忽略思考时间（Think Time），在“Runtime Setting——Think Time”中设置；
尽可能为每个页面设置一个事务，不然不知道哪一个页面最慢；
真正运行性能测试脚本时，关闭日志功能（在Runtime Setting设置），当咱们调试脚本时，能够打开日志功能；
性能测试前的数据准备很重要，设计并发用户数量应由少到多，逐渐递增（20—30—50—100）；
在性能测试时，每一个用户登陆的用户名和密码尽可能不要相同（用参数化设置）；
一般状况下，能够将登陆录制到Vuser_init部分中，将客户端活动录制到Actions部分中，将退出货注销过程录制到Vuser_end部分中；
在使用脚本时，能够参考LR API函数；