Threadgroup repetition without reseting CSV pointers ?

[Christian Schwanke <me...@gmx.de>]

Hi,

we want to run a test for several hours with a threadgroup of 10 threads on
a web application. We use the __CSVRead function to fill the different
HTTPSampler with values. The threadgroup is repeated in order to extend the
test over a longer period of time. 
This works fine since each thread reads a different line from the csv-data.
However, with each iteration of the threadgroup, the internal "pointer" to
the CSV-data is reset, so that each iteration produces the exact same HTTP
requests.

I think the current behaviour is absolutly correct since a repetition of a
test should produce the exact same output.
In my case, this behaviour is not what I want. I need each HTTP request to
be unique (it is a constraint of the webapp).
To my mind, the threadgroup repetition is the wrong way to achieve this. 
I'm considering changing the test plan to use a LoopController combined with
a Timer in order to create a single long-running testplan.

My question is: is there a better/smarter way of doing this ? Is it, for
example, possible to prevent the csv pointer from being reset ?

Thanks in advance for any ideas/help/etc :),

Christian

p.s: I know there are propably many reasons to doubt the constraint of
forcing unique requests - however, I cannot change that ;)



---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org

Re: Threadgroup repetition without reseting CSV pointers ?

[sebb <se...@gmail.com>]

On Tue, 14 Dec 2004 10:50:05 +0100 (MET), Christian Schwanke
<me...@gmx.de> wrote:
> Hi,
> 
> we want to run a test for several hours with a threadgroup of 10 threads on
> a web application. We use the __CSVRead function to fill the different
> HTTPSampler with values. The threadgroup is repeated in order to extend the
> test over a longer period of time.

Do you mean that you have two or more identical threadgroups?

> This works fine since each thread reads a different line from the csv-data.
> However, with each iteration of the threadgroup, the internal "pointer" to
> the CSV-data is reset, so that each iteration produces the exact same HTTP
> requests.
> 
> I think the current behaviour is absolutly correct since a repetition of a
> test should produce the exact same output.
> In my case, this behaviour is not what I want. I need each HTTP request to
> be unique (it is a constraint of the webapp).
> To my mind, the threadgroup repetition is the wrong way to achieve this.
> I'm considering changing the test plan to use a LoopController combined with
> a Timer in order to create a single long-running testplan.

Sounds better.

> My question is: is there a better/smarter way of doing this ? Is it, for
> example, possible to prevent the csv pointer from being reset ?

Not if it is in a different thread group. Thread groups are completely
independent.
But you could perhaps use a different file in each group.
 
> Thanks in advance for any ideas/help/etc :),
> 
> Christian
> 
> p.s: I know there are propably many reasons to doubt the constraint of
> forcing unique requests - however, I cannot change that ;)

[And why should you?]

We run some tests that last for a whole weekend.

These need to use unique values for each sampler in each thread (one
of the values is a PIN number that can only be used once)

The way we do this is to have a single threadgroup, with a loop
controller that contains a few samplers and usually a constant
throughput controller.

Data is read using _StringFromFile() as __CSVRead() would need too
much memory. We also use the feature whereby StringFromFile will stop
the thread when it runs out of data.

The loop controller is set to a high value (or -1 if we want it to
stop at end of data).

Note: the new __split() function can be used in conjunction with
_StringFromFile() to allow the use of  large CSV files. For small CSV
files, __CSVRead() is just as good.

S.

---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org