个人碰到比较常见的Loadrunner报错日志

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

5.
Loadrunner报错日志：

Connection reset by peer.

这个问题一般是由于下载的速度慢，导致超时，所以，需要调整一下超时时间。   

解决办法：Run-time setting窗口中的‘Internet Protocol’－‘Preferences’设置set advanced options（设置高级选项），重新设置一下“HTTP-request connect timeout（sec），可以稍微设大一些”。 

6、

Loadrunner报错日志：

connection refused 

这个的错误的原因比较复杂，也可能很简单也可能需要查看好几个地方，解决起来不同的操作系统方式也不同。   

1、首先检查是不是连接weblogic服务过大部分被拒绝，需要监控weblogic的连接等待情况，此时需要增加acceptBacklog，每次增加25%来提高看是否解决，同时还需要增加连接池和调整执行线程数，（连接池数*Statement Cache Size）的值应该小于等于oracle数据库连接数最大值。   

2、如果方法一操作后没有变化，此时需要去查看服务器操作系统中是否对连接数做了限制，AIX下可以直接vi文件limits修改其中的连接限制数、端口数，还有tcp连接等待时间间隔大小，wiodows类似，只不过windows修改注册表，具体修改注册表中有TcpTimedWaitDelay和MaxUserPort项，键值在[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\]。因为负载生成器的性能太好，发数据包特别快，服务器也响应特别快，从而导致负载生成器的机器的端口在没有timeout之前就全部占满了。在全部占满后，就会出现上面的错误。执行netstat –na命令，可以看到打开了很多端口。所以就调整TCP的time out。即在最后一个端口还没有用到时，前面已经有端口在释放了。   

1,这里的TcpTimedWaitDelay默认值应该中是30s，所以这里，把这个值调小为5s（按需要调整）。   

2,也可以把MaxUserPort调大（如果这个值不是最大值的话）。 

7、

Loadrunner报错日志：

open many files

问题一般都在压力较大的时候出现，由于服务器或者应用中间件本身对于打开的文件数有最大值限制造成，解决办法：   

1、修改操作系统的文件数限制，aix下面修改limits下的nofiles限制条件，增大或者设置为没有限制，尽量对涉及到的服务器都作修改。   

2、方法一解决不了情况下再去查看应用服务器weblogic的commonEnv.sh文件，修改其中的nofiles文件max-nofiles数增大，应该就可以通过了，具体就是查找到nofiles方法，修改其中else条件的执行体，把文件打开数调大。修改前记住备份此文件，防止修改出错。   

3、linux上可以通过ulimit –HSn 4096来修改文件打开数限制，也可以通过ulimit -a 来查看。   

4、linux上可以通过lsof -p pid | wc -l 来查看进程打开的句柄数

8、

Loadrunner报错日志：

has shut down the connection prematurely 

一般是在访问应用服务器时出现，大用户量和小用户量均会出现。   

来自网上的解释：   

1>应用访问死掉   

小用户时：程序上的问题。程序上存在数据库的问题   

2>应用服务没有死   

应用服务参数设置问题   

例如：   

在许多客户端连接Weblogic应用服务器被拒绝，而在服务器端没有错误显示，则有可能是Weblogic中的server元素的AcceptBacklog属性值设得过低。如果连接时收到connection refused消息，说明应提高该值，每次增加25％   

Java连接池的大小设置，或JVM的设置等   

3>数据库的连接   

在应用服务的性能参数可能太小了   

数据库启动的最大连接数（跟硬件的内存有关）   

以上信息有一定的参考价值，实际情况可以参考此类调试。   

如果是以上所说的小用户时：程序上的问题。程序上存在数据库的问题，那就必须采用更加专业的工具来抓取出现问题的程序，主要是程序中执行效率很低的sql语句，weblogic可以采用introscope定位，期间可以注意观察一下jvm的垃圾回收情况看是否正常，我在实践中并发500用户和600用户时曾出现过jvm锯齿型的变化，上升下降都很快，这应该是不太正常的。   

实际测试中，可以用telent 站点看看是否可以连接进去，可以通过修改连接池中的连接数和适当增加应用内存值，问题可以解决。

9、

Loadrunner报错日志：

Failed to connect to server

这个问题一般是客户端链接到服务失败，原因有两个客户端连接限制（也就是压力负载机器），一个网络延迟严重，解决办法：   

1、修改负载机器注册表中的TcpTimedWaitDelay减小延时和MaxUserPort增加端口数。注：这将增加机器的负荷。   

2、检查网络延迟情况，看问题出在什么环节。   

  建议为了减少这种情况，办法一最好测试前就完成了，保证干净的网络环境，每个负载机器的压力测试用户数不易过大，尽量平均每台负载器的用户数，这样以上问题出现的概率就很小了。

10、

Loadrunner报错日志：

Overlapped transmission of request to ... WSA_IO_PENDING

这个问题，解决方法：   

 1、方法一，在脚本前加入web_set_sockets_option("OVERLAPPED_SEND", "0")，禁用TTFB细分，问题即可解决，但是TTFB细分图将不能再使用，附图。   

2、方法二，可以通过增加连接池和应用系统的内存，每次增加25%。   

11、

Loadrunner报错日志：

Deleted the current transaction ... since response time is not accurate

这个问题不多遇见，一般出现在压力机器上发生ping值为负数（AMD双核CPU），可以重新启动pc机或者打补丁%。  

12、

Loadrunner报错日志：

HTTP Status-Code=500 (Internal Server Error) for

1、应用服务当掉，重新启动应用服务。   

2、当应用系统处于的可用内存处于阀值以下时，出现HTTP Status-Code=500的概率非常高，此时只要增加应用系统的内存，问题即可解决。  

13、

Loadrunner报错日志：

Failed to transmit data to network: [10057]Socket is not connected

这个错误是由网络原因造成的，PC1和PC2上面都装了相同的loadrunner 9.0，且以相同数量的虚拟用户数运行相同的业务（机器上的其他条件都相同），PC1上面有少部分用户报错，PC2上的用户全部执行通过。

14、

Loadrunner报错日志：

Error -27257: Pending web_reg_save_param/reg_find/create_html_param[_ex] request(s) detected and reset at the end of iteration number 1

解决方法：web_reg_save_param位置放错了，应该放到请求页面前面

15、

Loadrunner报错日志：

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

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

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

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

16、

Loadrunner报错日志：

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

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

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

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

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

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

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

17、

Loadrunner报错日志：

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”模式来录制脚本。

18、

Loadrunner报错日志：

error:missing newline in d:\loadrunner\name.dat   

场景执行时报error:missing newline in d:\loadrunner\name.dat   

第二次执行不报   

两个解决办法：   

第一：如果参数不是很多的话，不要打开记事本去编辑参数，就直接在LR提供的参数的表格中进行编辑即可。   

第二：如果参数很多超过100条的话。在记事本中编辑好了之后，记着在最后一个参数后打个回车，让鼠标的光标移动到下一行。

19、

Loadrunner报错日志：

load generator is currently running the maximum number of vuser of this type   

使用的是loadrunner8.0，有10000个用户的web的license，global的有10个。   

在测试的时候发现running vuser到达1000以后就不能再提高，后面的vuser就会出错。错误是“The load generator is currently running the maximum number of vuser of this type”.   

已经可以排除是load generator机器本身资源的问题。因为换了性能比较强的酷睿2还是同样的问题，CPU和memory都有空闲。   

解决办法:   

在load generator中有一个Vuser limits tab，可以设置running user的最大数目。 即设置 load generator----Details------Vuser limits ----Other Vusers 的最大参数

20、

Loadrunner报错日志：

sofeware caused connction：

这种情况，一般是脚本有问题，或者loadrunner有问题。解决方法：重新启动机器，或者重新录制脚本，估计是loadrunner的bug

21、

Loadrunner报错日志：

cannot connect to server:

无法连接到服务器。这种情况是服务器的配置有问题，服务器无法承受过多的并发连接了。需要优化服务器的配置，   

如操作系统采用windows 2003 server，   

优化tomcat配置：maxThreads="500" minSpareThreads="400" maxSpareThreads="450"。但是tomcat 最多支持500个并发访问   

优化apache配置：   

ThreadsPerChild 1900  

MaxRequestsPerChild 10000  

其他的错误如：   

Action.c(10): Error -27791: Server has shut down the connection prematurely   

HTTP Status-Code=503 (Service Temporarily Unavailable)   

一般都是由于服务器配置不够好引起的，按照问题（2）处理，如果仍旧不行，需要优化硬件和调整程序了。

22、

Loadrunner报错日志：

测试分析结果中会统计Action时间，而实际上可能并不须要这些数据，如何只显示自己定义的用户事务？

　　进入脚本的运行时设置，依次进入General→Miscellaneous。默认情况下，自动事务配置"Automatic Transactions"下有两个选项：第一个是把脚本的Action部分定义为一个事务；第二个时把脚本的每一部分定义为一个事务。去掉这两个勾选后，测试结果将会只显示自己定义的用户事务。

23、

Loadrunner报错日志：

测试结果中，Summary和平均事务响应时间图里的各个事务的最大值、平均值、最小值为什么显示不一样？

　　主要是受采样时间的影响。Summary里的事务平均响应时间是根据整个场景执行过程得到的数据计算所得，最大值与最小值也是从整个场景中得到的。平均事务响应时间图主要时按照LoadRunner分析出来的采样频率来获取事务响应时间的最大值与最小值，然后计算平均值。

　可以通过"Set Granularity"来修改平均事务响应时间图的采样频率。如果把"Granularity"设为场景执行时间，则统计结果将会一致。

24、

Loadrunner报错日志：

统计结果中的总点击量Total Hits时用户的鼠标点击次数吗？

　　Total Hits不时按照用户的鼠标点击次数来计算的，而是按照各个虚拟客户端向后台发起的总的请求数来进行统计的。例如在向服务器请求的一个页面中，如果该页面包含5个图片，用户只要单击鼠标就可以访问该页面，而单个虚拟用户在LoadRunner访问的点击量为1+5=6次。

25、

Loadrunner报错日志：

有些Web测试结果分析图（例如每秒返回页面数）在测试结果分析图中无法看到，如何进行配置？

　　用VuGen打开虚拟用户脚本后，进入"Run-time Settings"对话框后，依次进入"Internet Protocol>Preference"，可以看到一些Web性能图配置。

　　勾选上面得选项后，Controller将会在测试执行过程中生成数据，然后可在Analysis中查看相应的性能结果分析图。

Continue~~~~