LR性能测试应用

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

我总喜欢看那些陈旧的书，因为在我们忙碌的生活中，它又让我不经意间拾起了那一段记忆。一本好书，可以改变一个人的一生，是因为从中使用我得到知识的渴望和追求，不断地总结，不断地成长。。。。。。

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

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

一、提高篇：

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

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

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

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

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

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

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

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

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

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

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

总体上，LR的性能测试的工作流程大概如下：

1、创建脚本(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;

}

在我们录制了脚本后，可以完善脚本呢？

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

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

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

4、  插入LR API常用函数。

如：  web_custom_request();

Web_image();

Web_link();

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

参数化设置如下操作：

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

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

6、  脚本关联(手动关联)，操作步骤如下：

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

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

2、创建场景（Controller）

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

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

方案模式的选择有两种情况：一种是百分比方案模式，一种是面向目标的方案模式。如果用户需求比较明确，可以选择面向目标的方案模式，设置期望值。

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

3、结果分析(Analysis)

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

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

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

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

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

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

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

二、提高篇

设置关联：在脚本中设置手动关联一向是个难题，有些关联的地方是有多处，前面的关联如果没有执行通过，执行将停止验证脚本的正确性，后面需要做关联的部分无法被扫描出来。

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

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的客户端中配置服务名，步骤如下图：

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

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

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

4、下一步，选择协议：

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

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

若测试配置连接未成功，则需要 ”更改口令”，因为默认值为系统管理员的用户名和口令（都是“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/

三、实战篇

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

LR注意事项：

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