java vuser_JavaVuser性能测试（LoadRunner 一）

1、安装

操作系统使用Win2008_Server_R2_X64版本，LoadRunner使用11版本(安装过程不赘述)

注：操作系统安装成功后，请关闭防火墙并修改注册表中的Tcp参数

2、Tcp参数修改

注册表路径：HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/service/Tcpip/Parameters

增加DWORD值如下：

TcpNumConnections=1090584575

TcpTimeWaitDelay=30

MaxHashTableSize=65536

MaxFreeTcbs=2000

MaxUserPort=65534

3、实践中遇到的问题

a)脚本问题

被测对象是一个java服务，所以选用的是JavaVuser协议，下面是某个接口的测试脚本。

脚本中有三点需要注意：

1、应为并发请求速度很快，此请求服务器会返回一个流，所以需要对返回增加同步，否则拿到的resultStatus字段值可能为空。

2、将脚本中写文件的代码注释掉是因为写文件是客户端的操作，和服务器没关系，对服务器不产生压力却会拉高响应时间。

3、变量使用完后需要置空，因为LR默认的共享内存只有10M，内存不足会造成Controller和Load Generator通讯出现问题。

修改共享内存：\HP\LoadRunner\dat\channel_configure_merge.dat

注：被测对象不同，脚本写法也不同，根据实际情况调整。

b)参数化问题

1、LR默认参数化的最大数量是100条，可通过修改配置文件放大该值。

LR安装目录config/vugen.ini文件

2、多次对同一个参数进行不同的参数化。

如果有对一个参数进行多次参数化的需求且每次参数化使用的参数化文件都不一样，建议先将之前的参数化删除，不要直接覆盖，否则可能会出错。

c)某接口TPS低问题

测试过程中遇到几个有写库操作的接口TPS很低，排查之后怀疑是Mysql的问题，经过修改Mysql的参数，TPS提高了很多，满足需求。

修改文件为my.cnf，修改内容如下：

innodb_flush_log_at_trx_commit = 2  //先写缓存再写磁盘

sync_binlog = 1       //一次事务提交就写一次磁盘

这两个参数对mysql的性能影响很大，具体可晚上查资料了解

d)某接口出现大量no buffer space available问题

测试中遇到这样一个情况，有一个下载文件接口，下载55K文件，单客户机并发2K，出现大量no buffer space available，通过netstat –an命令查看，大量端口处于time_wait状态。查资料并和开发沟通怀疑是客户机Socket资源不够用，所以采用多个负载机的方式进行测试，下面将说明多个负载机遇到的问题及解决办法。

Step1：配置LoadRunner Agent Runtime Setting Configuration

在开始菜单—LoadRunner—Tools中以管理员身份打开此项，默认是第一项，需要输入负载机的用户名和密码。

注：所有负载机都需要进行此操作

Step2：配置Agent Configuration

在开始菜单—LoadRunner—Advanced Configuration中以管理员身份打开Agent Configuration，勾选第二项

注：所有负载机都需要执行此操作

Step3：Controller中添加负载机

打开Scenario—Load Generators

点击Add按钮

Name：负载机IP地址

Temporary directory：如果不填默认在负载机C盘根目录生成tmp文件夹，建议此项自定义一个路径。

填好之后可以测试下连接，Ready状态表示连接成功

注：使用负载机测试，脚本文件是不需要拷贝到负载机中的。

Step4：设置场景并开始run

But，出现了虚拟用户初始化失败的情况。

从错误信息中可以看出Script和Action都是None，说明脚本没有执行，这是为什么？

网上查了下资料，是因为脚本依赖的jar没有找到，导致脚本无法执行。赶紧将jar包从Controller拷贝一份到LoadGenerator相同的路径下。

再次Run，还是出现了上述问题，这就奇怪了，索性把脚本也拷贝一份到LoadGenerator，配置好Runtime后运行脚本，可以正常执行。但是到Controller中Run起来就会报错。没招了，不明白为啥，难道是脚本根本就没有从Controller传输到Load Generator中，为了证明这一点，需要进入Load Generator的工作目录中，也就是下图的Tmpporary directory，默认是C:/tmp

在C:/tmp目录下有一个netdir的目录，在此目录下找到的脚本文件，经查看，脚本文件是完整的，说明脚本没有问题，有查看了logfile，这时候发现还是因为有几个jar没有找到。很奇怪，既然缺少jar为什么单独调试脚本的时候可以通过呢？最后排查发现是因为Load Generator的lib库拷贝错了。重新拷贝lib库到Load Generator并再次执行脚本，可以正常运行了。

TCP  TIME_WAIT参考资料：

https://huoding.com/2013/12/31/316