Hi Michele, Jordi,
Please let me add participate in this discussion.
> That's a start many thanks,
> but the change proposed wouldn't allow to submit more requests than
> the web application could handle. If I wanted to send 10 reqs per sec
> and the response time was more than 1 sec, than I would have to increase
> the timer to be bigger than 1 sec, and we would still be
> stuck with in the same problem.
> Does this make sense?
I think Michele's suggestion differs from bugzilla's entry. Moreover, I feel
Michele's timer is not such simple problem to solve. Consider the main thread
loop:
while (controller.hasNext() && running) {
try
{
SamplePackage pack =
compiler.configureSampler(controller.next());
delay(pack.getTimers());
SampleResult result =
pack.getSampler().sample(null);
......
}
and delay method
private void delay(List timers) {
int sum = 0;
Iterator iter = timers.iterator();
while (iter.hasNext()) {
sum += ((Timer) iter.next()).delay();
}
if(sum > 0)
{
try {
Thread.sleep(sum);
}
catch (InterruptedException e) {
log.error("",e);
}
}
}
JMeter's timer is a simple interface witch just add some sleep in thread's
loop, witch one important function - delay.
Sampler's method "sample" waits for the response so jmeters timers have no
chance to act before receiving whole response. This idea don't fit into
jmeters framework (not easily at least) because jmeter's thread act's like
send request - receive response - wait some time
BTW: Michele: could you tell me what are you testing?. I'm testing web
applications with jMeter, and for me investigating application under stress
measured in request per second is somehow abstract. I'd rather want to check
how application respond to load of X users (X jMeter's thread) running some
scenario. User has to see previous response to click on it (and this fits
jmeters approach to the problem)
best regards
Michal
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
