image

编辑人: 长安花落尽

calendar2025-06-07

message6

visits804

LoadRunner性能测试常见的错误是什么?怎么解决的?

  1. Action.c(7): Error -27791: Server "10.10.0.88" has shut down the connection prematurely

    解决方案如下:


    1、应用服务器死掉。小用户时程序上的问题,程序上处理数据库的问题
    2、应用服务没有死。应用服务参数设置问题。例如:在许多客户端weblogic应用服务器被拒绝,而在服务器端没有错误显示,则有可能是weblogic中的server元素的acceptbacklog属性值设得过低。如果连接时收到connection refused消息,说明应提高该值,每次增加25%。
    3、数据库的连接,在应用服务的性能参数可能太小了;数据库启动的最大连接数(跟硬件的内存有关)
    4、有时关闭卡巴斯基也会解决如上问题

    优化方法: 我们用的是Tomcat, 然后我自己优化了tomcat配置,初始好像是maxThreads="500″ minSpareThreads="400″ maxSpareThreads="450″。

A.LR本身的设置:改变CONTROLLER中的CONNECT_TIME设置;

采用修改tools-options-修改connect的时间解决了
B. 应用程序:优化程序;
C. SERVER设置:优化APP,DB,WEB SERVER等设置;

2.Error: Failed to connect to server
"172.17.7.230″: [10060] Connection

  1. Error: timed out Error: Server "172.17.7.230″ has shut down the connection prematurely

分析:

A、应用服务死掉。(小用户时:程序上的问题。程序上处理数据库的问题,实际测试中多半是服务器链接的配置问题)

B、应用服务没有死(应用服务参数设置问题)对应的Apache和tomcat的最大链接数需要修改,如果连接时收到connection refused消息,说明应提高相应的服务器最大连接的设置,增加幅度要根据实际情况和服务器硬件的情况来定,建议每次增加25%!

C、数据库的连接(数据库启动的最大连接数(跟硬件的内存有关))

D、我们的应用程序spring控制的最大链接数太低

  1. Error: Page download timeout (120 seconds) has expired

分析:

A、应用服务参数设置太大导致服务器的瓶颈

B、页面中图片太多

C、在程序处理表的时候检查字段太大多

D、实际测试时有些资源需要请求外网,而我们的测试环境是局域网环境

5 Error "http://172.17.7.230/Home.do...."

分析:

A、脚本设计错误,造成页面异常。服务器有响应!

B、并发数过大,造成服务器响应延迟。

  1. Error page "text=xxxxx"

分析:

A、脚本设计问题,例如,前一脚本修改了某些内容,造成后面的脚本访问异常。

B、不确定因素,有时候回放正常的脚本,一放到场景中就出现这样的错误。只能反复修改脚本!

  1. Action.c(16): Error -27728: Step download timeout (120 seconds) has expired when downloading non-resource(s)。

错误分析:对于HTTP协议,默认的超时时间是120秒(可以在LoadRunner中修改),客户端发送一个请求到服务器端,如果超过120秒服务器端还没有返回结果,则出现超时错误。

解决办法:首先在运行环境中对超时进行设置,默认的超时时间可以设置长一些,再设置多次迭代运行,如果还有超时现象,需要在"Runtime Setting">"Internet Protocol:Preferences">"Advanced"区域中设置一个"winlnet replay instead of sockets"选项,再回放是否成功。

  1. Action.c(81):Continuing after Error -27498: Timed out while processing URL=http://172.18.20.70:7001/workflow/bjtel/leasedline/ querystat/ subOrderQuery.do

错误分析:这种错误常常是因为并发压力过大,服务器端太繁忙,无法及时响应客户端的请求而造成的,所以这个错误是正常现象,是压力过大造成的。

如果压力很小就出现这个问题,可能是脚本某个地方有错误,要仔细查看脚本,提示的错误信息会定位某个具体问题发生的位置。

解决办法:例如上面的错误现象问题定位在某个URL上,需要再次运行一下场景,同时在其他机器上访问此URL。如果不能访问或时间过长,可能是服务器或者此应用不能支撑如此之大的负载。分析一下服务器,最好对其性能进行优化。

如果再次运行场景后还有超时现象,就要在各种图形中分析一下原因,例如可以查看是否服务器、DNS、网络等方面存在问题。

最后,增加一下运行时的超时设置,在"Run-Time Settings">"Internet Protocol:Preferences"中,单击"options",增加"HTTP-request connect timeout" 或者"HTTP-request receive"的值。

9.LoadRunner脚本中出现乱码:在录制Web协议脚本时出现中文乱码,在回放脚本时会使回放停止在乱码位置,脚本无法运行。

错误现象:某个链接或者图片名称为中文乱码,脚本运行无法通过。

错误分析:脚本录制可能采用的是URL-based script方式,如果程序定义的字符集合采用的是国际标准,脚本就会出现乱码现象。

解决办法:重新录制脚本,在录制脚本前,打开录制选项配置对话框进行设置,在"Recording Options"的"Advanced"选项里先将"Surport Charset"选中,然后选中支持"UTF-8″的选项。

10.LoadRunner HTTP服务器状态代码:在录制Web协议脚本回放脚本的过程中,会出现HTTP服务器状态代码,例如常见的页面-404错误提示、-500错误提示。

错误现象1: -404 Not Found服务器没有找到与请求URI相符的资源,但还可以继续运行直到结束。

错误分析:此处与请求URI相符的资源在录制脚本时已经被提交过一次,回放时不可再重复提交同样的资源,而需要更改提交资源的内容,每次回放一次脚本都要改变提交的数据,保证模拟实际环境,造成一定的负载压力。

解决办法:在出现错误的位置进行脚本关联,在必要时插入相应的函数。

错误现象2: -500 Internal Server Error服务器内部错误,脚本运行停止。

错误分析:服务器碰到了意外情况,使其无法继续回应请求。

解决办法:出现此错误是致命的,说明问题很严重,需要从问题的出现位置进行检查,此时需要此程序的开发人员配合来解决,而且产生的原因根据实际情况来定,测试人员无法单独解决问题,而且应该尽快解决,以便于后面的测试。

11.LoadRunner请求无法找到:在录制Web协议脚本回放脚本的过程中,会出现请求无法找到的现象,而导致脚本运行停止。

Action.c(41): Error -27979: Requested form. not found [MsgId: MERR-27979]

Action.c(41): web_submit_form. highest severity level was "ERROR",0 body bytes, 0 header bytes [MsgId: MMSG-27178]" 这时在tree view中看不到此组件的相关URL。

错误分析:所选择的录制脚本模式不正确,通常情况下,基于浏览器的Web应用会使用"HTML-based script"模式来录制脚本;而没有基于浏览器的Web应用、Web应用中包含了与服务器进行交互的Java Applet、基于浏览器的应用中包含了向服务器进行通信的JavaScript/VBScript代码、基于浏览器的应用中使用HTTPS安全协议,这时则使用"URL-based script"模式进行录制。

解决办法:打开录制选项配置对话框进行设置,在"Recording Options"的"Internet Protocol"选项里的"Recording"中选择"Recording Level"为"HTML-based script",单击"HTML Advanced",选择"Script. Type"为"A script. containing explicit"。然后再选择使用"URL-based script"模式来录制脚本。

12.LoadRunner不执行检查方法:在录制Web协议脚本中添加了检查方法Web_find,但是在脚本回放的过程中并没有执行。

错误现象:在脚本中插入函数Web_find,在脚本中设置文本以及图像的检查点,但是在回放过程中并没有对设置的检查点进行检查,即Web_find失效。

错误分析:由于检查功能会消耗一定的资源,因此LoadRunner默认关闭了对文本以及图像的检查,所以在设置检查点后,需要开启检查功能。

解决办法:打开运行环境设置对话框进行设置,在"Run-time Settings"的"Internet Protocol"选项里的"Perference"中勾选"Check"下的"Enable Image and text check"选项。

13.LoadRunner回放Web Services协议脚本错误:LoadRunner 8.0版本在录制Web Services协议的脚本时正常,但在回放时会出现错误,提示停止脚本运行。

错误现象:利用LoadRunner 8.0版本来录制Web Services协议的脚本没有任何错误提示,回放脚本时会出现如下错误提示"Error:server returned an incorrectly formatted SOAP response"。

错误分析:出现此错误的原因是LoadRunner8.0在录制Web Services协议的脚本时存在一个缺陷:如果服务器的操作系统是中文的,VuGen会自动将WSDL文件的头改为<?xml version="1.0″encoding="zh_cn" ?>,所以才会有此错误提示。

解决办法:下载两个补丁,分别为"LR80WebServicesFPI_setup.exe"和"lrunner_web_ services_patch_1.exe"安装上即可。

Action.c(8): Error -26612: HTTP Status-Code=500 (Internal Server Error) for "http://10.2.35.123:9081/perbankDemo/login"

二.监控指标数据分析

1.Vusers数

Loadrunner 系统设置的虚拟用户数目。Vuser去实际调用事先制作的脚本文件中的应用。

每个Vuser产生响应的操作,所有的操作对服务器形成并发。

颜色 比例 度量 图最小值 图平均值 图最大值 图中间值 图SD

1 Run 0.0 21.25 44 41 21.276

在实际测试中,Vusers可以根据实际情况的需要,在测试过程中增加或者减少。

2.最大并发用户数:

颜色 比例 度量 最小值 平均值 最大值 SD

100 Apache CPU 使用情况(Apache):172.17.7.210 0.777 0.852 0.93 0.043

0.01 已发送 KB/秒(Apache):172.17.7.210 6 1430.371 2689.333 327.924

0.1 点击次数/秒(Apache):172.17.7.210 0.333 114.352 533.667 40.201

应用系统在当前环境下能承受的最大并发用户数。

在方案运行中,如果出现了大批用户的业务操作失败,或出现了服务器shutdown的情况,

则说明在当前环境下,系统承受不了当前并发用户的负载压力,那么最大并发用户数就是前一个没有出现这种现象的并发用户数。

从上图可以看出:在测试运行到4个小时左右的时候,apache的点击数/秒开始迅速增加!

3.业务操作响应时间:

使用"事务性能摘要"图,可以确定在方案执行期间响应时间过长的事务。

颜色 比例 度量

1 最小值

1 平均值

1 最大值

分析事务的响应情况,要每次详细分析,目前还只能观察到响应时间过长的事务!

4.每秒点击数

负载测试期间每秒内 Vuser 在 Web 服务器上点击的次数。可根据点击次数来估算 Vuser 生成的负载数。

颜色 比例 度量 图最小值 平均值 图最大值 图中间值 图SD

1 点击次数 69.908 105.736 130.244 103.666 12.186

从图中不难看出,在4小时的时候,点技数明显增高。和apache的每秒点击数增大的时间相吻合!

5.吞吐量

负载测试期间 Web 服务器上的吞吐量(字节)。吞吐量表示在任何指定秒内 Vuser 从服务器接收到的数据量。此图可估计 Vuser 生成的负载量(服务器吞吐量)。

颜色 比例 度量 图最小值 平均值 图最大值 图中间值 图SD

loadrunner监控Windows之前需要做的准备工作

Error -26612: HTTP Status-Code=500 (Internal Server Error) ...

分类:
测试学习 2009-04-16 20:35 6781人阅读
评论(7) 收藏
举报

最近在测试一系统的时候,录制脚本没有错误,回放的时候总是出现如下错误:
Action.c(6): Error -26612: HTTP Status-Code=500 (Internal Server Error) for "http://192.168.0.110:7001/logonConsole.do;jsessionid={JSESSIONID2}"

造成HTTP-500错误,有朋友告诉我如下几个可能:

1、运行的用户数过多,对服务器造成的压力过大,服务器无法响应,则报HTTP500错误。减小用户数或者场景持续时间,问题得到解决。

2、该做关联的地方没有去做关联,则报HTTP500错误。进行手工或者自动关联,问题得到解决。

3、录制时请求的页面、图片等,在回放的时候服务器找不到,则报HTTP500错误,若该页面无关紧要,则可以在脚本中注释掉,问题将会得到解决。例如:有验证码的情况下,尽管测试时已经屏蔽了,但是录制的时候提交了请求,但回放的时候不存在响应。

4、参数化时的取值有问题,则报HTTP500错误。可将参数化列表中的数值,拿到实际应用系统中进行测试,可排除问题。

5、更换了应用服务器(中间件的更换,如tomcat、websphere、jboss等),还是利用原先录制的脚本去运行,则很可能报HTTP500错误。因为各种应用服务器处理的机制不一样,所录制的脚本也不一样,解决办法只有重新录制脚本。

6、Windows xp2 与ISS组件不兼容,则有可能导致HTTP500错误。对ISS组件进行调整后问题解决。

7、系统开发程序写的有问题,则报HTTP500错误。例如有些指针问题没有处理好的,有空指针情况的存在。修改程序后问题解决。




喵呜刷题:让学习像火箭一样快速,快来微信扫码,体验免费刷题服务,开启你的学习加速器!

创作类型:
原创

本文链接:LoadRunner性能测试常见的错误是什么?怎么解决的?

版权声明:本站点所有文章除特别声明外,均采用 CC BY-NC-SA 4.0 许可协议。转载请注明文章出处。
分享文章
share