>> > > 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... 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. I might flag a test saying that you didn't maintain a rate of throughput because of CO. 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. > In some cases it may not be possible avoid the CO, but in other cases, > it should be possible to reduce the transaction rate in each thread > such that long sample times don't cause the next sample to be delayed. I think the way around CO due to threads not being available is to simply not reuse them. Since I've been using JMeter that way I find that my tests are working much better. HTTP is sync which means I'm not sure about how to fix the problem that Gil is taking about without a very serious work around. > And at least the user will have the required information. > > So, I'll ask again: is my proposal for *detecting* CO reasonable? > If not, what changes are needed? I think detection is reasonable.. it's how the problem is dealt with afterwards is something that needs discussion. > > Changing JMeter to behave differently is a matter for a separate thread. Since the problems are coupled together I'd take this as a tactical hack to start to deal with the problem... which is a good start! Thanks, Kirk > >> Regards, >> Kirk >> >> >> On 2013-10-18, at 12:27 AM, sebb <[email protected]> wrote: >> >>> It looks to be quite difficult to avoid the issue of Coordination >>> Omission without a major redesign of JMeter. >>> >>> However, it may be a lot easier to detect when the condition has occurred. >>> This would potentially allow the test settings to be changed to reduce >>> or eliminate the occurrences - e.g. by increasing the number of >>> threads or spreading the load across more JMeter instances. >>> >>> The Constant Throughput Controller calculates the desired wait time, >>> and if this is less than zero - i.e. a sample should already have been >>> generated - it could trigger the creation of a failed Assertion >>> showing the time difference. >>> >>> Would this be sufficient to detect all CO occurrences? >>> If not, what other metric needs to be checked? >>> >>> Even if it is not the only possible cause, would it be useful as a >>> starting point? >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
