On 18 October 2013 20:01, Kirk Pepperdine <[email protected]> wrote: >>> >> >> I think you have missed the point of my posting. > > No, I just got excited that the problem is finally being looked at again 8*) > >> >> The idea was to detect when CO has happened, and use that information >> to change the test setup. > > I just wouldn't fail a test based on it occurring. A result is a result and > should be treated as such.. good or bad...
A 404 or 500 is a result as well, but it results in a failed sample. > Instead I'd offer a correction. In this case the correction would be to > detect when the sampler should have been fired and add that time to the > response time. That would not be correct either. There's no way of knowing what the actual elapsed time would have been had the sample been started at the correct time. The correct offset is probably somewhere between zero and the delay, but even that is conjecture, as it's possible that the sample would have failed had it been started earlier. > I might flag a test saying that you didn't maintain a rate of throughput > because of CO. That was the point of creating the Assertion. Maybe there are better ways to flag the problem up, but it would be a start. > My problem with the threading model is that response times are upper bounded > by a value that is a function of the number of threads. This can result in > JMeter having unwanted effects on response times. Yes, but please let's try and deal with one problem at a time. This thread is about how to detect (and report) CO. I suggest this is dealt with first before getting into discussions of possible timing adjustments and avoidance techniques. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
