Patrick and I were discussing User Abandonment this afternoon and he posed a very interesting question. He wanted to understand why we issue an LR_ABORT when an abandonment threshold has been achieved. The problem as we both see it is that an LR_ABORT forces the LoadRunner VUser to STOPPED state. That means if we have 5 VUsers running continuous iterations and 1 abandons, we only have 4 VUsers running continuously. The alternative would be to simply stop the iteration and move on to a new iteration with the same VUser.
My memory is completely failing me as to why we designed it this way. I think it had to do with capturing the slope of abandonment and the rate of arrival. We wanted VUser to leave the scenario because our thoughts were that they abandoned primarily because of saturation of resources or queuing of interfaces.
What we are seeing are more software performance issues in which we are not interface or resource saturated. Rather, we have under-performing transactions. As a result, our VUsers prematurely abandon. I think we need to rethink issuing an LR_ABORT. I am not quite sure what we are to do in its place. I’m thinking on the lines of ending the iteration, but not a full LR_ABORT. We could also look into issuing multiple chances before an abort. For example, we could say allow the VUser to abandon the iteration X amount of times. When X is achieved, then issue an LR_ABORT. Seriously, I am open to suggestions.
I’m going to think about this a little bit more. I welcome others in the group to offer code samples and/or suggestions.