51Testing软件测试论坛

标题: 关于非正常响应时间的分析，还有一个棘手问题，希望大家多多给点意见 [打印本页]

作者: qunslh 时间: 2013-11-13 11:31
标题: 关于非正常响应时间的分析，还有一个棘手问题，希望大家多多给点意见
本帖最后由 qunslh 于 2013-11-14 08:49 编辑

小弟最近在给公司一产品做性能测试，再一次做数据录入场景，出现了一些数据自己读不明白，希望大家帮帮忙一起看看
[attach]88004[/attach]
这是50Vuser下的响应时间图

下次测试加大了jvm xmx值，加到1536兆，同时Vuser上升到了100
[attach]88005[/attach]
这是100vuser下的响应时间图

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

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

作者: 云层 时间: 2013-11-13 22:29
1.看不到图片
2.你处理的时候参数化或者关联不对，导致业务问题

作者: qunslh 时间: 2013-11-14 11:13
本帖最后由 qunslh 于 2013-11-14 11:45 编辑

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

还是没有思路。

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

多谢多谢，辛苦了

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

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

作者: qunslh 时间: 2013-11-14 11:23
回复 4# tianlang001
多谢多谢，我试试换换迭代方式。

作者: tianlang001 时间: 2013-11-14 11:33
回复 6# qunslh

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

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

作者: qunslh 时间: 2013-11-14 11:38
回复 7# tianlang001
好吧我打字慢了

作者: 云层 时间: 2013-11-14 13:09

回复云层
感谢云层大大，我买过你的书哦，下次应该求你签名。
我觉得你书写的很详细很全面，就是个人感 ...
qunslh 发表于 2013-11-14 11:22

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

作者: 云层 时间: 2013-11-14 13:11
你知道Id是什么预先参数化分配就行了，就没问题了，应该还是你参数分配的错误问题

作者: tianlang001 时间: 2013-11-14 15:51
回复 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中删除掉

作者: qunslh 时间: 2013-11-15 14:00
回复 12# tianlang001
你说的意思我明白了，但是我参数化的id是服务器返回的，不是在dat文件中，服务器一次只返回第一个数据的id。
这....

作者: tianlang001 时间: 2013-11-15 22:44
回复 13# qunslh

好吧，我没明白你的了，不知道你服务器的返回机制是怎么回事

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