51Testing软件测试论坛

标题: Loadrunner与Jmeter真的node.js性能测试结果差异太大 [打印本页]

作者: iOrchid 时间: 2013-10-23 14:10
标题: Loadrunner与Jmeter真的node.js性能测试结果差异太大
RT。
最近项目提供了一个node.js开发的http协议的接口，功能异常简单，但是还是需要做下压力测试，检测咱工具到底性能怎样。无一例外，选择loadrunner，录制脚本，然后跑起来。好，问题出现了，node.js服务端的内存持续上涨！暗笑~
但是开发排查不出来原因，他们自己用jmeter进行了测试，诡异的问题来了，内存平稳，响应时间比loadrunner快很多！
好郁闷啊，最近也查了很多资料，loadrunner和jmeter统计存在差异是有的，但是没有出现过一个内存上涨、一个平稳的现象啊。
坑啊~node.js服务端几乎没有什么操作，就是把内存中的数据经过计算返回给客户端；loadrunner脚本就一个web_url函数调用服务端；jmeter也就添加了一个http请求。各位同行好友，有没有什么思路可以指导一二，万谢！

作者: iOrchid 时间: 2013-10-23 14:52
回复 1# iOrchid

感谢审贴大大如此快发布此贴。此问题会一直跟踪并且如有结果会立即更新。但是现在还请各位给点思路撒~~

作者: tianlang001 时间: 2013-10-23 17:40
服务器什么系统，容器是什么呢，还有你统计内存是用什么统计的，LR？

作者: tianlang001 时间: 2013-10-23 17:42
服务器什么系统，容器是什么，统计内存用什么统计的呀，LR？

作者: iOrchid 时间: 2013-10-23 18:55
目前怀疑是Jmeter模拟http请求不合理。依据是使用Jmeter并发100路时，服务端监控的句柄数就是100（隔30s获取一次数据），使用Loadrunner并发100路时，服务端监控的句柄数是存在浮动的。根据有限的知识：http请求应该是需要先建立socket连接，最后需要端口socket连接，如果有socket断连操作的话，句柄数应该是有变化的。据此怀疑开发使用Jmeter时的脚本中没有socket断连操作。对此还需验证，不知各位有没有好的验证方法。多谢！

作者: iOrchid 时间: 2013-10-23 18:56
目前怀疑是Jmeter模拟http请求不合理。依据是使用Jmeter并发100路时，服务端监控的句柄数就是100（隔30s获取一次数据），使用Loadrunner并发100路时，服务端监控的句柄数是存在浮动的。根据有限的知识：http请求应该是需要先建立socket连接，最后需要端口socket连接，如果有socket断连操作的话，句柄数应该是有变化的。据此怀疑开发使用Jmeter时的脚本中没有socket断连操作。对此还需验证，不知各位有没有好的验证方法。多谢！

作者: iOrchid 时间: 2013-10-23 18:56
回复 2# iOrchid

目前怀疑是Jmeter模拟http请求不合理。依据是使用Jmeter并发100路时，服务端监控的句柄数就是100（隔30s获取一次数据），使用Loadrunner并发100路时，服务端监控的句柄数是存在浮动的。根据有限的知识：http请求应该是需要先建立socket连接，最后需要端口socket连接，如果有socket断连操作的话，句柄数应该是有变化的。据此怀疑开发使用Jmeter时的脚本中没有socket断连操作。对此还需验证，不知各位有没有好的验证方法。多谢！

作者: iOrchid 时间: 2013-10-24 08:32
本帖最后由 iOrchid 于 2013-10-24 09:16 编辑

回复 3# tianlang001

目前已经初步验证之前的猜想，Loadrunner模拟的是整个http调用过程，从建立socket连接一直到断开socket连接；而Jmeter则是在一个socket连接中进行请求。
验证方法是使用Loadrunnersocket协议编写脚本，把建立连接放在init中，把断开连接放在end中，action中只做请求。如此运行场景的结果与Jmeter执行的结果是一致的。故此，基本验证猜想。
如果猜想正确，则可以推断出，Jmeter在一个socket连接中不停的向服务端发送请求，以此着重验证我们代码的逻辑，因为一般http请求中的socket管理是有底层服务的任务，开发人员负责的是对接收到的请求进行处理，至于socket连接管理则不需要开发人员关注。据了解node.js的http server是这样。而Loadrunner则完全是模拟用户的行为，它模拟了完整的http请求，对服务端的测试更为真实完整。

接下来需要做的就是排查node.js的http管理服务为何出现泄漏问题。

对此，不知各位是否有好的思路，多谢！

作者: qinzl_1 时间: 2013-10-25 09:15
我也发现这样的问题，loadrunner并发100个，查看服务端的tcp连接数能接近400的并发，jmeter的线程数在500，查看服务器的连接数最高就在100而且浮动很大，监控服务端的网络占用量loadrunner是jmeter的10倍多，真心怀疑jmeter的是否能产生压力

作者: qinzl_1 时间: 2013-10-25 09:16
我也发现这样的问题，loadrunner并发100个，查看服务端的tcp连接数能接近400的并发，jmeter的线程数在500，查看服务器的连接数最高就在100而且浮动很大，监控服务端的网络占用量loadrunner是jmeter的10倍多，真心怀疑jmeter的是否能产生压力

作者: tianlang001 时间: 2013-10-25 17:34
回复 8# iOrchid

嗯，想起来了，这是socket的长短连接问题，长连接一直不断，就只是建立连接的时候使用了下内存，当然平稳，短连接会不停使用内存，内存上涨估计是因为加压期间断开的短连接没有释放内存，造成内存泄露。

作者: iOrchid 时间: 2013-10-29 11:58
回复 11# tianlang001

后来开发又验证了之前的猜测，貌似Jmeter与Loadrunner没有区别，最后也有断开socket的操作，之前猜测有误。
目前怀疑是Node.js版本的问题，在0.10.15版本上，100tps的压力下，内存仍然增长；替换为0.8
版本后，在100tps压力下，内存稳定。目前在最新版本上进行验证。Node.js 0.10.15版本可能改变了内部GC策略，降低了GC频率，导致内存没有释放。
多谢各位帮助！

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)