发布新日志

  • 【转】loadrunner监控windows资源注意项

    2013-03-20 10:21:39

    Loadrunner监控windows资源时注意项：

    1、被监控服务器，需开启下述三个服务：
    server
    Remote Procedure Call(RPC)
    Remote Registry


    2、监控端，运行-net use\\IP\ipc$/user:administrator passwd
    net use\\被监控服务器IP\ipc$/user:administrator administrator的密码
    提示：命令成功完成

    3、如果上述命令没有成功完成；
    确认：
    安全策略的设置问题（管理工具 -> 本地安全策略 -> 安全选项 ->“网络访问：本地帐户的共享和安全模式”）。默认情况下，XP的访问方式是“仅来宾”的方式，如果你访问它，当然就固定为Guest来访问，而 guest账户没有监控的权限，所以要把访问方式改为“经典”模式，这样就可以以administrator的身份登陆了。修改后，再次执行步骤2

    查看(220) 评论(0) 收藏 分享 管理

  • 【转】关于LR事务成功数与实际入库数不一致的问题解决

    2013-03-20 10:20:54

    之前在做公司机场项目性能测试的时候，遇到这样类似的问题：
    功能作为DLL封装调用，在脚本中设定一投注事务，该事务是往数据库中插入数据，调试全部成功。当设定场景Vuser为1，思考时间为0，运行10分钟后，事务通过数量为40220，数据库中的数据也是40220，该过程无错误提示。

    初始化数据后，Vuser设置为50，思考时间为1，运行6分钟后，事务通过数量为3819，数据库中的数据也是3068，该过程无错误提示。成功入库率的只有80%，这一情况反映了实际入库的结果与事务通过数量不符。
    后Vsuer设为100，继续测试，仍然不符。

    因此看来，LR的事务与实际业务并不是强制一一对应的关系。有可能事务处理成功，但实际业务会遇到一些问题，可不知道如何下手去判断问题出在哪里。
     
    问题解决：
    lr的事物pass是代表在特定的时间内服务响应，有数据返回，是物理上的pass，但是数据库中数据需要成功插入，则需要逻辑上pass才能成功插入数据。一个是代码问题，一个是数据语句的问题。
     

    查看(1308) 评论(0) 收藏 分享 管理

  • 【转】关于Loadrunner-27796错误

    2013-03-20 10:07:39

    在性能测试过程中，大家都可能遇到过LR-27796错误，此类错误屡见不鲜..在走访了各大论坛后，发现大侠们给出的各类的版本的27796错误，那么27796是如何产生的呢？接下来跟大家分享下我的所得与感想

    在测试一个web站的接口项目中，出现了大量的27796错误（此报错代码有很多种错误提示，比如：27796—Failed to connect to server、27796—timeout、27796-No Route To Host等），根据LR的帮助提示是修改注册表的两个键值后方可解决，我试着修噶了注册表，重启了机器，在喜气冲冲的进行新的一轮压测过程中发现，错误木有解决，依然存在27796错误。我开始在网上搜索此问题的处理办法，说法云云：1、重启机器、2、修改注册表、3、更换操作系统（囧）我发现对我木有效果，出现错误的请求占总请求的20%左右，这个比例压测是无任何意义的！心灰意冷....

    我开始从第一个27796—Failed to connect to server开始查找原因，如果出现连接失败，肯定是客户端与服务器端的通信出现了问题导致的，不论外界原因，实质就是通信!
    我试着使用网络工具wireshark在LoadRunner开启时，抓取通信信息。问题出现了，在监测通讯过程中发现，问题出现在第二次握手，客户端已经发出syn包，但服务器端没有接受到syn包，
    当timewait三秒钟后再次发出syn包，服务器端可以接收到此包，问题出现了，就是说这个请求在没有建立连接时就出现错误了，神奇了！！！
    客户端与服务器端
    建立连接如下：
    第一次　　第一次握手：建立连接时，客户端发送syn包(syn=j)到服务器，并进入SYN_SEND状态，等待服务器确认；SYN：同步序列编号(Synchronize Sequence Numbers)。第二次　　第二次握手：服务器收到syn包，必须确认客户的SYN（ack=j+1），同时自己也发送一个SYN包（syn=k），即SYN+ACK包，此时服务器进入SYN_RECV状态； 
    　　
    三次握手

    第三次　　第三次握手：客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK(ack=k+1)，此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手。

    问题找到原因了，那么这些不同的27796有那些问题，如何产生的呢？

    答案1：大家可能有手工编写脚本的习惯，大家使用最多的协议应该是web/http协议，那么GET、POST请求是最常见的，例如：web_url("www.baidu.com",                 "URL=http://www.baidu.com", 
                    "Resource=0", 
                    "RecContentType=text/html", 
                    "Referer=", 
                    "Snapshot=t2.inf", 
                    "Mode=HTML", 
                    LAST);
    这段代码中我们来分析下，如果把以上代码修改为
         web_url("www.baidu.com",                 "URL=http://www.baidu.com",
                    LAST);
    请求是否成功？答案是肯定是，可以发起get请求。那么大家实验过没有如果这样的话，在压测过程中是否出现过问题？LR会出现27796错误，大家可以实验下，那么问题出在那呢？问题就出现在自己的代码中，缺少RecContentType=text/html类型导致GET请求出现问题，服务器端无法识别请求携带的标示，所以自己的代码编写是27796产生的一部分

    原因2：这个是摘自百度的帖子"因为负载生成器的性能太好，发数据包特别快，服务器也响应特别快，从而导致负载生成器的机器的端口在没有timeout之前就全部占满了。在全部占满后，就会出现上面的错误。执行netstat –na命令，可以看到打开了很多端口。所以就调整TCP的time out。即在最后一个端口还没有用到时，前面已经有端口在释放了"
    说白了点，就是端口没有释放掉timeout状态，没有恢复到监听的状态，所以此时做好的办法就是，重启电脑恢复这些端口占用的状态，当重启机器后，查看状态netsat -nao 后，如果恢复到正常端口的状态，就可以再次进行性能测试了。

    原因3：第三个原因
    在性能测试i过程中，可能出现服务器资源利用率过高，导致建立连接失败现象，此类错误应该查看服务器的资源利用率，如果出现了资源利用过高现象，27796的错误也会在此时产生！27796的错误一般都是由于建立连接失败而导致的，建立连接失败的原因有很多种情况，大家只要明白其中27796的产生错误的实质就可以了，在大家测试过程中欢迎大家跟帖，在什么情况出现的这种错误，如何解决的继续下去！

    查看(12226) 评论(0) 收藏 分享 管理

Open Toolbar