51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 2748|回复: 13
打印 上一主题 下一主题

[求助] 关于非正常响应时间的分析,还有一个棘手问题,希望大家多多给点意见

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2013-11-13 11:31:26 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
本帖最后由 qunslh 于 2013-11-14 08:49 编辑

小弟最近在给公司一产品做性能测试,再一次做数据录入场景,出现了一些数据自己读不明白,希望大家帮帮忙一起看看

这是50Vuser下的响应时间图

下次测试加大了jvm xmx值,加到1536兆,同时Vuser上升到了100

这是100vuser下的响应时间图

对着Vuser的增加响应时间增加这可以理解,但是这两张图片里都有响应时间在很高的情况下骤然下降的情况,
实在不好理解,希望知道的朋友能详细解释一下。


还有一个小问题是我要做一个上报的测试,已经有了好几万条,每个记录都有自己的唯一id,靠这个id对该记录进行操作,
问题是当我整好脚本,回放完全正常,但在负载是时候出现了大量用户同时访问一个id的错误,造成服务器经常未响应,事务失败。
关于这个问题,希望高手能给个测试的思路。
多谢!

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有帐号?(注-册)加入51Testing

x
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏
回复

使用道具 举报

该用户从未签到

2#
发表于 2013-11-13 22:29:46 | 只看该作者
1.看不到图片
2.你处理的时候参数化或者关联不对,导致业务问题
回复 支持 反对

使用道具 举报

该用户从未签到

3#
 楼主| 发表于 2013-11-14 11:13:48 | 只看该作者
本帖最后由 qunslh 于 2013-11-14 11:45 编辑

回复 2# 云层
可能第二个问题我没有说清楚
现在情况是这样的,有几万数据,每条数据都有一个自己的id,现在取第一个数据的id,
对这个数据操作结束后,这个数据就没了,下一条数据顶上,成了第一条,以此类推。
脚本参数化我参数化了第一条用户的id,脚本没问题,参数化也正常,lr_output_message也能正确输出id值,
但是多用户同时运行脚本时有很大概率有部分用户拿到同一个id操作,造成服务器未响应。
如果用单用户操作,循环Action(对数据的操作放到Action里面了)可能会解决这个问题,但这就不是并发了,而且云层大大的性能进阶测试那本书中好像提过脚本中不建议循环Action。

还是没有思路。

至于第一个问题,图片现在好了,问什么会有响应时间先上升后骤降的情况呢。

多谢多谢,辛苦了
回复 支持 反对

使用道具 举报

该用户从未签到

4#
发表于 2013-11-14 11:15:27 | 只看该作者
感觉20个用户就达到最佳了,3、40s的响应时间客户能接受么
这种情况有时会出现的,不好解释,估计是因为运行队列堵塞造成的,你可以想象成一个通道,一直在堵着,突然疏通,然后又堵上了,具体原因让高手答下吧
参数化数据提取方式选唯一,Unique那个,数据更新方式选每次迭代,Each iteration
回复 支持 反对

使用道具 举报

该用户从未签到

5#
 楼主| 发表于 2013-11-14 11:22:19 | 只看该作者
回复 2# 云层
感谢云层大大,我买过你的书哦,下次应该求你签名。
我觉得你书写的很详细很全面,就是个人感觉你书里面对数据库性能测试感觉讲的不太详细,尤其是javaVuser处理数据库,你只给了个sqlServer的例子(jdbc连接数据库做增删改查),
但没有具体给出怎么用loadrunner监控数据库性能的操作(只能看出响应时间,其他性能数据得靠其他软件)。
希望在下个版本能稍微在数据库方面写详细点。
个人意见,个人意见,仅供参考。
回复 支持 反对

使用道具 举报

该用户从未签到

6#
 楼主| 发表于 2013-11-14 11:23:40 | 只看该作者
回复 4# tianlang001
多谢多谢,我试试换换迭代方式。
回复 支持 反对

使用道具 举报

该用户从未签到

7#
发表于 2013-11-14 11:33:20 | 只看该作者
回复 6# qunslh


    只要出现这种每个记录都有自己的唯一数据的场景,差不多都是使用这种迭代方式的,注意一点,数据一定要够,总量是按用户数*迭代次数来算的
迭代次数可以参考  加压时间/业务基准时间
回复 支持 反对

使用道具 举报

该用户从未签到

8#
 楼主| 发表于 2013-11-14 11:36:23 | 只看该作者
回复 4# tianlang001
有几万条数据,每个数据都有唯一的id,
现在有这个操作,每次取第一个数据(通过id),对这个数据操作结束后,这条数据没了,下条顶上,成了第一条,继续之前的操作,以此类推。
脚本没问题,参数化了第一条数据的id,参数化也保证没问题。
如果用单用户,循环Action(Action里面是主要数据操作),不会出现错误,但这就不是并发操作了。
如果用多用户,那么就有可能会出现有部分用户拿到重复的id值。如果这种情况,需要怎么处理?
多谢多谢,辛苦辛苦!
回复 支持 反对

使用道具 举报

该用户从未签到

9#
 楼主| 发表于 2013-11-14 11:38:14 | 只看该作者
回复 7# tianlang001
好吧 我打字慢了
回复 支持 反对

使用道具 举报

该用户从未签到

10#
发表于 2013-11-14 13:09:57 | 只看该作者
回复  云层
感谢云层大大,我买过你的书哦,下次应该求你签名。
我觉得你书写的很详细很全面,就是个人感 ...
qunslh 发表于 2013-11-14 11:22


你可能没看其中的一段话,我就不推荐用lr监控别的东西,监控数据库?直接上spotlight或者别的工具了,谁还用LR啊。
回复 支持 反对

使用道具 举报

该用户从未签到

11#
发表于 2013-11-14 13:11:08 | 只看该作者
你知道Id是什么预先参数化分配就行了,就没问题了,应该还是你参数分配的错误问题
回复 支持 反对

使用道具 举报

该用户从未签到

12#
发表于 2013-11-14 15:51:00 | 只看该作者
回复 8# qunslh


    你说的这种就是用unique,不过要自己手动控制下数据,不要一次放完
假设5用户并发,数据有 1-25,运行5分钟,总共迭代了5次(假设事务时间是1分钟),那么数据分配方式就是
用户1,   1、2、3、4、5
用户2,   6、7、8、9、10
以此类推
...
用户5,   21、22、23、24、25
用完后,这批数据就作废了的,下次再次运行要更换参数里的值,这种数据只能靠手动控制,你要是一次把所有数据都放进去进行分配,那就悲剧了,后面跑的时候你不知道哪些已经跑过了
所以让你计算一次加压需要多少数据,多1点点就行了,你的几万个数据够你这样测了

或者你把用过的数据输出出来,每次加压后把这些数据从参数的dat中删除掉
回复 支持 反对

使用道具 举报

该用户从未签到

13#
 楼主| 发表于 2013-11-15 14:00:37 | 只看该作者
回复 12# tianlang001
你说的意思我明白了,但是我参数化的id是服务器返回的,不是在dat文件中,服务器一次只返回第一个数据的id。
这....
回复 支持 反对

使用道具 举报

该用户从未签到

14#
发表于 2013-11-15 22:44:13 | 只看该作者
回复 13# qunslh


    好吧,我没明白你的了,不知道你服务器的返回机制是怎么回事
回复 支持 反对

使用道具 举报

本版积分规则

关闭

站长推荐上一条 /1 下一条

小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

GMT+8, 2024-11-6 11:38 , Processed in 0.073589 second(s), 27 queries .

Powered by Discuz! X3.2

© 2001-2024 Comsenz Inc.

快速回复 返回顶部 返回列表