RE: User Parameters Pre Processor
Thank you both.
I didn't notice this difference.
It make sense now.
www.beatsoo.org - free application performance monitoring from world wide
locations.
On Mar 24, 2014 4:30 PM, "Robin D. Wilson" wrote:
> I think it is because a 'config element' is processed once when the test
> plan is loaded, but a 'pre-processor' is processed before each sample is
> run. There is a similar 'config element' called "User Defined Variables"
> that are processed at load-time for the test case. But bear in mind, if you
> use these - only the last one in the whole test plan is valid for a given
> variable. Whereas, if you use "User Parameters" those are valid for a
> specific sample based on the how they are defined as the test case is
> processing.
>
> For example, say you have a test plan that looks like this:
>
> User Defined Variables: username = foobar
> Thread Group 1: (uses '${username}' variable)
> User Defined Variables: username = notfoobar
>
> In this case, when you run the test plan, the ${username} variable will be
> set to "notfoobar" - because the "User Defined Variables" are all processed
> _before_ the thread group runs - and the value is set to the last one that
> defined it.
>
> In example 2, we see User Parameters at work:
>
> Thread Group 1:
> User Parameter: username = foobar${__threadNum}
> Sampler A: (uses ${username} variable)
> Thread Group 2:
> User Parameter: username = notfoobar${__threadNum}
> Sampler B: (uses ${username} variable)
>
> In this example, Thread Group 1 will increment the 'username' value
> through "foobar1", "foobar2", etc. for as many different threads as you run
> through it. Likewise, thread group 2 will increment the username variable
> through "notfoobar1", "notfoobar2", etc. because the User Parameters are
> evaluated at the sample run time.
>
> --
> Robin D. Wilson
> Sr. Director of Web Development
> KingsIsle Entertainment, Inc.
> VOICE: 512-777-1861
> http://www.kingsisle.com
>
> -Original Message-
> From: Shmuel Krakower [mailto:shmul...@gmail.com]
> Sent: Monday, March 24, 2014 3:03 AM
> To: JMeter Users List
> Subject: User Parameters Pre Processor
>
> Hi,
> I was wondering why the User Parameters is a pre-processor rather than a
> Config Element?
> I just spent few minutes looking for it in the wrong place... ;)
>
> Best,
>
> Shmuel Krakower.
> www.Beatsoo.org - re-use your jmeter scripts for application performance
> monitoring from worldwide locations for free.
>
>
> -
> To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org
> For additional commands, e-mail: user-h...@jmeter.apache.org
>
>
RE: User Parameters Pre Processor
I think it is because a 'config element' is processed once when the test plan
is loaded, but a 'pre-processor' is processed before each sample is run. There
is a similar 'config element' called "User Defined Variables" that are
processed at load-time for the test case. But bear in mind, if you use these -
only the last one in the whole test plan is valid for a given variable.
Whereas, if you use "User Parameters" those are valid for a specific sample
based on the how they are defined as the test case is processing.
For example, say you have a test plan that looks like this:
User Defined Variables: username = foobar
Thread Group 1: (uses '${username}' variable)
User Defined Variables: username = notfoobar
In this case, when you run the test plan, the ${username} variable will be set
to "notfoobar" - because the "User Defined Variables" are all processed
_before_ the thread group runs - and the value is set to the last one that
defined it.
In example 2, we see User Parameters at work:
Thread Group 1:
User Parameter: username = foobar${__threadNum}
Sampler A: (uses ${username} variable)
Thread Group 2:
User Parameter: username = notfoobar${__threadNum}
Sampler B: (uses ${username} variable)
In this example, Thread Group 1 will increment the 'username' value through
"foobar1", "foobar2", etc. for as many different threads as you run through it.
Likewise, thread group 2 will increment the username variable through
"notfoobar1", "notfoobar2", etc. because the User Parameters are evaluated at
the sample run time.
--
Robin D. Wilson
Sr. Director of Web Development
KingsIsle Entertainment, Inc.
VOICE: 512-777-1861
http://www.kingsisle.com
-Original Message-
From: Shmuel Krakower [mailto:shmul...@gmail.com]
Sent: Monday, March 24, 2014 3:03 AM
To: JMeter Users List
Subject: User Parameters Pre Processor
Hi,
I was wondering why the User Parameters is a pre-processor rather than a Config
Element?
I just spent few minutes looking for it in the wrong place... ;)
Best,
Shmuel Krakower.
www.Beatsoo.org - re-use your jmeter scripts for application performance
monitoring from worldwide locations for free.
-
To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org
For additional commands, e-mail: user-h...@jmeter.apache.org
Re: User Parameters Pre Processor
On 24 March 2014 08:03, Shmuel Krakower wrote: > Hi, > I was wondering why the User Parameters is a pre-processor rather than a > Config Element? > I just spent few minutes looking for it in the wrong place... ;) Partly "because it is". Partly because Pre-Processors are processed before every sample; Config elements are not. > Best, > > Shmuel Krakower. > www.Beatsoo.org - re-use your jmeter scripts for application performance > monitoring from worldwide locations for free. - To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org For additional commands, e-mail: user-h...@jmeter.apache.org
