LoadRunner案例分析之四
2,791 Views『作者：RickyZhu 转载务必注明出处和作者』
Tag:loadrunner
最近在论坛上看到几次这样的问题，今天突然想起来，觉得比较典型，有必要分析一下。
这个问题的具体描述大概是这样的：在web应用下，模拟十个用户并发进行数据的添加，结果每次执行全部成功，但是数据却不是十条，每次数据不一样，但是都比十小。
乍一看，可能是数据参数化的问题，其实仔细想想，道理其实很简单。是数据库的问题。
大多数的数据库都有记录锁的问题，第一次的数据操作没有commit之前，第二次对同样表进行的操作可能就没有办法成功。所以每次数据的条数都达不到十条。但是为什么每次都不一样呢？这个问题也容易解释，因为每次的操作服务器的响应时间是不同的，所以不同虚拟用户的提交时间也不是不同的，这样一来，就导致每次提交成功的数据量不一致。导致每次结果的条数可能是不同的。
其实这个问题，跟LoadRunner的使用并没多大关系，而主要是对数据库的了解和应用执行机制的了解。如何解决这个问题，我现在还没有好的思路，是否对应用程序写数据库的过程作一些改进？大家可以一起探讨。
有点不同的看法。
文中提到：在web应用下，模拟十个用户并发进行数据的添加，结果每次执行全部成功，但是数据却不是十条，每次数据不一样，但是都比十小。
——既然每次都有一些提交没有成功插入到数据库中，不知又如何判断“结果每次执行全部成功”的？对于没能完成插入数据库操作的那些请求，是否返回了错误页面？
个人认为这样下了定论似乎缺乏有力的证据啊。
从事务的角度，他的提交成功了，但是没有进行页面的检查，很有可能事务返回了错误页面提示。但是从Database的角度，却是失败的事务。注意两个事务是不同的概念，一个是LoadRunner中的事务，一个是Database的事务。
我的意思是：
1.从你上面的文章来看，没有明确的证据表明案例中的请求失败是由于数据库的问题导致的；
2.我们使用性能测试工具模拟的“事务”是从用户角度来说的——我这里说的事务指的并不是 LR 中通过 lr_start_transaction 和 lr_end_transaction 来定义的那个“事务”，如果一个请求没有能够正确的完成，那么这个事务是不能算成功的。另外，在这个案例中，因为没有在脚本中添加 check point，所以用来作分析的 result 应该是不充分的，不应该根据不充分的 result 来下一个结论。
^_^
1. According to my experience, most probably the reason is caused by database lock.
2. From the end user(that’s customer) point of view, the transaction maybe failed, but from the LoadRunner’s test result, it’s succeed, so my suggestion is we add check point in the script to trace this issue. So, I agree with you that we could not make final conclusion on this case. ^_^