性能测试loadrunner使用共性问题汇总

2.3 共性问题

2.31 虚拟客户脚本“Run-time Setting”中的线程和进程运行方式的区别？

如果选择“Run Vuser as a process”，则场景运行时会为每一个虚拟用户创建一个进程；选择“Run Vuser as a thread”则将每个虚拟用户作为一个线程来运行，在任务管理器中只看到一个mmdrv.exe，这种方式的运行效率更高，能造成更大的压力，时默认选 项。

另外，如果启用了IP欺骗功能，则先在Controller中选中Tools菜单下的“Expert Mode”，然后将Tools菜单下的“Options>General”标签页中的IP地址分配方式也设置为与Vuser运行方式一致，同为线程或进程方式。

2.32 thinktime与pacing的设置对脚本及场景的影响

在我测试的过程中在稳定性测试场景中有一次我对场景中的一个脚本取消了pacing设置，结果导致VU退出，出现了内存冲突的错误。

在我们测试中BancsLink_C63601_C63603_短信功能定制和删除、 BancsLink_C60422_C60423_活期与定期批次转出关联、BancsLink_C67050_C67000_修改客户信息提示等交易，不加thinktime时也会报错。

首先我们要明确设置他们的意义。

Pacing是通过设置两次迭代之间的间隔时间，来调整各个action之间的步调。从定义上来看，它是和iteration绑定在一起的。Pacing的设置可以调节系统压力的大小，影响系统处理事务的能力。在场景运行中pacing的设置是很重要的。

Think time是通过设置思考时间，来模拟真实用户在操作过程中的等待时间。从定义上来看，它是在iteration内部的某个action中各个步骤的间隔时间，主要目的在于模拟真实用户操作情况，在测试中使虚拟用户对业务的操作更接近实际。

示例：假设用户进行一次操作会消耗5秒钟的时间，即完成整个迭代需要5秒钟。如果用户不停顿，继续第二次重复操作，则同样耗费约5秒左右的时间。但是真实世 界中肯定是有停顿的。一个真正的用户，做完一系列操作后，会间隔一段时间。假定用户停顿了5秒，再第二次重复操作，则一共耗费10秒钟时间。映射到 loadrunner中，就需要在一次iteration中，设置一个thinktime = 1秒，然后在两个iteration之间，设置一个pacing为5秒。

2.33 在运行场景中两个vu并发时交易出现错误，在脚本中没有出现这种情况。

查看日志发现两vu所使用的参数值是一样的，所以在接收报文时VU不能对应的找到自己的接收报文。

解决办法

1、在场景中修改VU家在策略，有一次全部加载改为逐步加载。

2、改变取参策略，把数据分块，然后分到固定的VU。

2.34 题描述Deleted the current transaction ... since response time is not accurate

出现这个问题时TPS大幅下降，VU并没有掉。这个问题不多遇见，在调试稳定性测试场景中遇到几次。一般出现在压力机器上发生ping值为负数时，可以重新启动pc机或者打补丁，如果还不行把场景另存.

2.35 日志缓存过小：to Log cache is too small to contain the message.

由于场景中Auto Log cache默认设置为1k，但是遇到报文较长的交易时自动日志缓存的容量就太小了我们就得手动修改。

2.36 运行中掉VU。

1、出现Action.c(35): Error : save param parameter is invalid. Error code : 9005. Error -- memory violation : Exception ACCESS_VIOLATION received.

内存冲突的问题很普遍，有些程序设置之间的冲突也会导致这个错误，就脚本里来讲，HTTP录制的脚本里面关联错误会导致内存冲突；在socket协议的脚本里判断成功时我们一般采用字母、数字与存储在缓冲区里的报文做匹配，但是我们存在缓冲区里面的报文是二进制格式的，所以在场景中也会造成内存冲突，最后掉VU。可能一个很小的问题就会引起内存冲突。

2、内存资源不足：脚本中的事务执行后没有释放buffer，最好在每个事务结束后就释放buffer。

3、压力过大：压力过大导致本地存储收回报文的存储空间不足，写不了日志也会掉VU

4、参数取值不正确也可能导致掉VU

5、系统自身原因。

总体来说，解决方法就是调整脚本、分成多台压力机进行测试。

2.37 为什么Windows系统中的CPU、内存等资源仍然充足，但是模拟的用户数量却上不去?

在Windows计算机的标准设置下，操作系统的默认限制只能使用几百个Vuser，这个限制与CPU或内存无关，主要是操作系统本身规定了默认的最大线程数所导致。要想突破Windows这个限制，须修改Windows注册表。以Windows XP Professional为例。

(1)打开注册表后，进入注册表项HKEY_LOCAL_MACHINE中的下列关键字：SystemCurrentControlSetControlSession ManagerSubSystems。

(2)找到Windows关键字，Windows关键字如下所示：

%SystemRoot%system32csrss.exe bjectDirectory=Windows

SharedSection=1024,3072,512 Windows=On SubSystemType=Windows ServerDll=basesrv,1

ServerDll=winsrv:UserServerDllInitialization,3 ServerDll=winsrv:ConServerDllInitialization,2

ProfileControl=Off MaxRequestThreads=16

SharedSection=1024,3072,512关键字的格式为xxxx,yyyy,zzz。其中，xxxx定义了系统范围堆的最大值(以KB为单位)，yyyy定义每个桌面堆得大小。

(3)将yyyy的设置从3072更改为8192(即8MB)，增加SharedSection参数值。

通过对注册表的更改，系统将允许运行更多的线程，因而可以在计算机上运行更多的Vuser。这意味着能够模拟的最大并发用户数量将不受Windows操作系统的限制，而只受硬件和内部可伸缩性限制的约束。

2.38 问题描述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 来查看进程打开的句柄数。

2.38 LoadRunner与服务器连接时遇到的问题

（1）ERROR:sck connect Aborted

这种错误一般是软件造成连接中断。由于软件错误，造成一个已经建立的连接被取消，比如LoadRunner自身的bug，在发报文时多位。典型情况下，这意味着连接是由于协议或超时错误而被取消的。

（2）ERROR：Failed to connect to server

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

1、 修改负载机器的tcpdelaytime注册表键值，将其改小改小；

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

为了减少这种情况，最好测试中有个干净的网络环境，每个负载机器的压力测试用户数不易过大，尽量平均每台负载器的用户数，这样以上问题出现的概率就会减小。

（3）ERROR:has shut down the connection prematurely

分为以下三种情况：

1.应用访问死掉

小用户时：程序上的问题或数据库的问题 ，应该查看一下sql执行效率和JAV的垃圾回收情况，具体定位问题。

2.应用服务没有死

应用服务参数设置问题

例如：

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

3. 数据库的连接

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

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

(4)ERROR: connection refused.

这种情况比较复杂，需要检查几个地方，不同的操作系统也会有不同的操作方式。

1．首先检查是不是连接weblogic服务大部分被拒绝，监控weblogic的连接等待情况，可能与上面的一样需要增加AcceptBacklog，如果没有解决问题，还要增加增加连接池，调整线程数，（连接池数*Statement Cache Size）的值应该小于数据库连接数的最大值。

2．查看服务器的操作系统中是否对连接数做了限制，AIX下可以直接编辑limit文件，修改连接数、端口数的限制以及tcp连接等待时间的间隔大小。若是windows系统，则要修改其注册表，修改TcpTimeWaitDelay（默认值30s）和MaxUserPort（可以调到小于最大值）项，键值在HKEY_LOCAL_MACHINESYSTEMCurrentControlSetTcpipParameters。因为当负载生成器的性能很好时，发数据包特别快，服务器响应也很快，从而导致负载生成器的端口在没有timeout之前就占满了。端口没有可用的时候就会出现错误，。执行netstat-na命令，可以查看端口。如果调整了TCP的timeout，情况会好点，在端口还没有占满前就有释放的了。