Just to know if my thoughts is on the right way, for this case. If you put a delay after your HTTP Sampler with a dynamic delay timing, considering you could use a post-processor to, say, calculate time spent on the request and set the delay time to (60000 - SpentTime). This way you'll have your 1 request per minute requirement. Configure the loop count Test Plan field and *voila*.
Other way is using Ramp up to distribute your request in a pre-defined time period between each request (easier to configure IMO). Don't know if it'll be possible, but, IMO, ideas are always welcome. Hope it helps you. Flávio Cysne 2012/3/12 Marcelo Jara <[email protected]> > > Well, iteration count is only used for debugging or when creating new > samplers only. I would gladly share my test plan with you if you want to > look at it. I already posted the requirements for the test. This system has > over a dozen consumers and exposes over 120 services. So each service must > be hit independently which is why a separate thread group is needed for > each sampler. This is my first jmeter test plan and I don't doubt that I > may be doing something fundamentally wrong. > > > Date: Sat, 10 Mar 2012 22:57:54 -0800 > > From: [email protected] > > To: [email protected] > > Subject: Re: Constant Throughput Timer and test duration conflict > > > > If you operate with fixed test duration, then iteration count makes no > sense, > > because the same test duration may include different iterations, > depending > > on server response time. > > Well, all I hear about your case tells me that there's something may be > > inefficient in your approach. > > Maybe you should choose stress-test mode as your primary performance > > criteria. Just my opinion. > > > > ----- > > -- > > Andrey Pohilko > > JP@GC Maintainer > > -- > > View this message in context: > http://jmeter.512774.n5.nabble.com/Constant-Throughput-Timer-and-test-duration-conflict-tp5533559p5554206.html > > Sent from the JMeter - User mailing list archive at Nabble.com. > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > >
