事务数与实际入库结果不一致的问题
功能作为DLL封装调用，在脚本中设定一投注事务，该事务是往数据库中插入数据，调试全部成功。当设定场景Vuser为1，思考时间为0，运行10分钟后，事务通过数量为40220，数据库中的数据也是40220，该过程无错误提示。初始化数据后，Vuser设置为50，思考时间为1，运行6分钟后，事务通过数量为3819，数据库中的数据也是3068，该过程无错误提示。成功入库率的只有80%，这一情况反映了实际入库的结果与事务通过数量不符。
后Vsuer设为100，继续测试，仍然不符。
因此看来，LR的事务与实际业务并不是强制一一对应的关系。有可能事务处理成功，但实际业务会遇到一些问题，可不知道如何下手去判断问题出在哪里，希望再此讨论。 是的，lr的事物pass是代表在特定的时间内服务响应，有数据返回，是物理上的pass，而你数据库中数据是需要逻辑上pass才能成功插入。 LS 说的好，学习了 本帖最后由 wensy 于 2011-12-14 14:00 编辑
按照二楼的理解，这种不一致性应该算是正常的情况了，而不应该算作是一种瓶颈？！
可是这仍将带来一些疑问。。如果实际使用情况真是如测试预期所料，大量的事务并发投出，是不是数据库一样有不一致的入库结果呢？这难道还能说是正常的么？
在实际测试中，事务先被触发，然后触发的事务再触发业务逻辑，这业务逻辑就是写入数据库的操作。我想知道，前者完成而后者未完成，这种现象是被快速的事务循环迭代了（不同的事务触发了同一业务逻辑）么？触发的业务逻辑没有跟上事务触发的步伐么？需要进一步的确认。 我觉得这不是正常也不是异常
我也遇到过楼主的问题，因为vuser数的本质是执行脚本的线程数，并且由于基准测试中是没问题的，所以我可以暂时相信lr确实执行过脚本的
所以，我首先从业务角度和数据库限制考虑，例如线程中并发情况：比如1线程执行成功100%，10线程执行成功90%，这样的随着线程数的提高，成功率反而降低，是否考虑过“并发”的问题？ to mr.bee
你说的这种情况，是的确存在。每当我增加Vuser的数量，成功率反而降低。从我的例子中可以看出，只有在我做Vuser为1的时候，即使没有思考时间，插入数据量非常巨大以及迅速的时候，它们仍然是一致的（事务数和入库结果），这验证了你的说法。
由于是使用DLL封装了一个投注功能，我用的连接协议是Win Socket，运行Vuser的方式是以进程的方式，而不是线程。这是因为线程的连接总是有连接10054的错误（socket0 - Connection reset by peer. Error code : 10054），后改为进程模式，有了明显的改善。其中，对数据库服务器SQLServer的监控表明，User Connection的值总是25，即便我用200个Vuser的时候也是一样的。
这样，我就会又有一些怀疑出现了，是不是SQLServer总是在用一些固定的进程或线程接收我的请求呢？而不是随之加大？又或者是我的应用本身就定义了这种进程或线程的模式?
貌似问题开始清晰和明了了很多。。。 to mr.bee
你所说的这种情况是存在的。根据测试的情况就是这样，随着Vuser的数量越多，事务数量与入库的结果差距就会越大。以我的测试为依据，当Vuser为1时，即使没有思考时间，快速的出票也能导致快速的入库。但若换成是Vuser50或提高至100，设置相应的思考时间，出票没有那么迅速了，但实际入库结果却出现了误差。
由于是封装的DLL实现出票功能，故使用Win Socket的协议进行的脚本。我没有使用线程的方式运行的Vuser，而是使用进程。这是因为在使用线程的时候总是会报10054错误（socket0 - Connection reset by peer. Error code : 10054）。
有一点值得注意，在测试的监控过程中，我发现SQLServer数据库的User connection指标一直保持为25，无论Vuser是50还是100，通过对数据库的查看，Running的活动连接数也仅仅为1个。这让我很是不解。难道是我的应用本身对SQLServer限制住了进程或线程的使用么？按照这样去设想，无论多少的事务同时触发，都会由固定的线程或进程去处理，导致Vuser越多，事务数量与实际结果差异越大的可能。这似乎证实了这一现状。
貌似问题越来越清晰起来。。 回复 7# wensy
那就好 继续深入的分析这个问题，想必没有那么简单。
当前能够得出的结论是，事务成功，数据丢失。这一现象伴随两个参数成正比，1是并发用户数，2是思考时间。
这两个参数越高，丢失率就越高。
并发数量的增多，会带来这样的问题，不难理解。但思考时间的延长为何也会出现这样的情况呢？ 回复 9# wensy
不知道楼主提出“思考时间”是做过什么样子的对比呢？同vuser下，思考按照50%回放和100%回放和150%，丢失率是呈现增长趋势么？ 关注 不有分说，找开发分析问题，很大程度上是程序写的有问题，建议让开发在程序里加插入成功信息标志，加异常显示信息，然后楼主再执行并发。
这种情况本人也遇到很多了，有时程序同步没控制好，有时是程序里创建socket问题，关于通讯的程序你最好别太相信开发，并发、多线程的问题经验多开发人员也是很难控制的。
你这边LR可以加调用dll信息，记录你执行了多少次调用操作，他那边加插入成功标志，两边对比，还有就是要分析你给参数的方式等等 回复 10# mr.bee
是的，肯定是经过对比才得出的结论。
举例：如果是100Vuser并发执行，开始的ThinkTime 为1s，执行结果发现成功率是80%的比例。
调整ThinkTime 为3s，成功率只有62%
但是，我将思考时间注释掉，执行结果成功率为95%的比例。
这类的样本同样的在150，200的Vuser上进行，得出了相一致的结论 个人觉得很可能是楼主检查点设置问题。如果没有检查点，LR是根据请求是否有响应来判断事务是成功还是失败，比如说：web协议返回HTTP200状态码LR会让事务通过。如果你设置了检查点，他会根据你设置的检查点来判断是否成功。 你的检查点是否完全设置正确了呢？ 功能作为DLL封装调用，在脚本中设定一投注事务，该事务是往数据库中插入数据，调试全部成功。当设定场景Vus ...
wensy 发表于 2011-12-13 18:10 http://bbs.51testing.com/images/common/back.gif
loadrunner对结果的正常性不做判定的。建议增加验证点就可以解决这个问题，不同的协议使用方法不一样的。
如：web_reg_find ； socket:lrs_save_param("socket1", NULL, "param1", 206, 17);
当然数据库也有自己的函数验证方法。。。 增加检查点,是可以算出事务数.但我还是不明白,为什么增加了思考时间,反而成功率下降?
单纯增加检查点,恐怕还不能足够分析该问题, 需要加debug代码,同时关注数据库等的日志.. 增加检查点,是可以算出事务数.但我还是不明白,为什么增加了思考时间,反而成功率下降?
单纯增加检查 ...
nighteblis 发表于 2011-12-24 23:02 http://bbs.51testing.com/images/common/back.gif
多线程问题不是能推断出规律的！开发人员都不一定搞不清楚多线程并发后回出现什么结果。 本帖最后由 wensy 于 2011-12-27 16:01 编辑
问题找到，特来结贴
问题：
投注事务成功，数据丢失。这一现象伴随两个参数成正比，1是并发用户数，2是思考时间。这两个参数越高，丢失率就越高。
原因：
由于投注事务前存在一个登录事务，是登录事务失败导致的。
解释：
1、并发用户数越多，登录失败的也就越多，故此投注失败率也就越高
2、思考时间越长，一部分登录成功的Vuser的投注的频率也就越慢，故失败率越高。
验证：
所有用户采用延迟登录（1s），所有投注全部成功。
LR只认为把事务开始和事务结束作为事务通过的标准，但这并不代表事务实际处理的结果是通过的。有效的打印日志信息将可靠的排除错误和定位错误
页:
[1]
