You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@jmeter.apache.org by Karel Vervaeke <ka...@outerthought.org> on 2008/08/18 15:13:07 UTC
load test PUT requests with variables in request body
Hi, I am writing a load test for an application and I need to send
PUT requests where the request body contains variable data.
I have a (theoretical) strategy for solving it, but I would like to know
if there are better ways to do it.
My current strategy is like this:
ThreadGroup
+ BeanShell script to create /tmp/requestbody-${discriminator}.xml
+ Sampler PUT /testme/123 => PUTs the
+ BeanShell script to clean up /tmp/requestbody-${discriminator}.xml
The ${discriminator} variable should be unique per thread so that each
thread can read/write to its own file.
Do you think this is a valid approach or am I going to hit some walls?
Is there another (better) approach?
Regards,
Karel
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: load test PUT requests with variables in request body
Posted by Karel Vervaeke <ka...@outerthought.org>.
On Mon, 2008-08-18 at 23:25 +0100, sebb wrote:
> On 18/08/2008, Karel Vervaeke <ka...@outerthought.org> wrote:
> > For future reference: it seems to work smoothly.
> > It took most of my time to figure out I needed to download the bsh jar
> > file to $JMETER_HOME/lib.
> >
> > For ${discriminator} I used ${__threadNum}.
> > The PUT request uses /tmp/requestbody-${__threadNum}.
> >
> > Currently the beanshell script is executed once for every thread
> > iteration so the file gets regenerated every time. It is not really
> > necessary (and probably causing a lot of overhead), but it could
> > probably use a variable to generate the file only once for every thread.
>
> If each file only needs to be generated once for each thread, then why
> not generate them before starting JMeter?
That should also work, but it seemed nicer if the jmeter test handled
everything so that the jmx file is self-contained. Your suggestion with
the loop controller looks like a good idea.
Thanks,
Karel
>
> Alternatively, you could use the following structure:
>
> Thread Group (loops = 1)
> + BeanShell Sampler (create file & return null)
> + Loop Controller (loops = n)
> + + main body of test
> + BeanShell Sampler (delete file & return null)
>
> > Regards,
> >
> > Karel
> >
> >
> > On Mon, 2008-08-18 at 15:13 +0200, Karel Vervaeke wrote:
> > > Hi, I am writing a load test for an application and I need to send
> > > PUT requests where the request body contains variable data.
> > >
> > > I have a (theoretical) strategy for solving it, but I would like to know
> > > if there are better ways to do it.
> > >
> > > My current strategy is like this:
> > >
> > > ThreadGroup
> > > + BeanShell script to create /tmp/requestbody-${discriminator}.xml
> > > + Sampler PUT /testme/123 => PUTs the
> > > + BeanShell script to clean up /tmp/requestbody-${discriminator}.xml
> > >
> > > The ${discriminator} variable should be unique per thread so that each
> > > thread can read/write to its own file.
> > >
> > > Do you think this is a valid approach or am I going to hit some walls?
> > > Is there another (better) approach?
> > >
> > > Regards,
> > > Karel
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: load test PUT requests with variables in request body
Posted by sebb <se...@gmail.com>.
On 18/08/2008, Karel Vervaeke <ka...@outerthought.org> wrote:
> For future reference: it seems to work smoothly.
> It took most of my time to figure out I needed to download the bsh jar
> file to $JMETER_HOME/lib.
>
> For ${discriminator} I used ${__threadNum}.
> The PUT request uses /tmp/requestbody-${__threadNum}.
>
> Currently the beanshell script is executed once for every thread
> iteration so the file gets regenerated every time. It is not really
> necessary (and probably causing a lot of overhead), but it could
> probably use a variable to generate the file only once for every thread.
If each file only needs to be generated once for each thread, then why
not generate them before starting JMeter?
Alternatively, you could use the following structure:
Thread Group (loops = 1)
+ BeanShell Sampler (create file & return null)
+ Loop Controller (loops = n)
+ + main body of test
+ BeanShell Sampler (delete file & return null)
> Regards,
>
> Karel
>
>
> On Mon, 2008-08-18 at 15:13 +0200, Karel Vervaeke wrote:
> > Hi, I am writing a load test for an application and I need to send
> > PUT requests where the request body contains variable data.
> >
> > I have a (theoretical) strategy for solving it, but I would like to know
> > if there are better ways to do it.
> >
> > My current strategy is like this:
> >
> > ThreadGroup
> > + BeanShell script to create /tmp/requestbody-${discriminator}.xml
> > + Sampler PUT /testme/123 => PUTs the
> > + BeanShell script to clean up /tmp/requestbody-${discriminator}.xml
> >
> > The ${discriminator} variable should be unique per thread so that each
> > thread can read/write to its own file.
> >
> > Do you think this is a valid approach or am I going to hit some walls?
> > Is there another (better) approach?
> >
> > Regards,
> > Karel
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: load test PUT requests with variables in request body
Posted by Karel Vervaeke <ka...@outerthought.org>.
For future reference: it seems to work smoothly.
It took most of my time to figure out I needed to download the bsh jar
file to $JMETER_HOME/lib.
For ${discriminator} I used ${__threadNum}.
The PUT request uses /tmp/requestbody-${__threadNum}.
Currently the beanshell script is executed once for every thread
iteration so the file gets regenerated every time. It is not really
necessary (and probably causing a lot of overhead), but it could
probably use a variable to generate the file only once for every thread.
Regards,
Karel
On Mon, 2008-08-18 at 15:13 +0200, Karel Vervaeke wrote:
> Hi, I am writing a load test for an application and I need to send
> PUT requests where the request body contains variable data.
>
> I have a (theoretical) strategy for solving it, but I would like to know
> if there are better ways to do it.
>
> My current strategy is like this:
>
> ThreadGroup
> + BeanShell script to create /tmp/requestbody-${discriminator}.xml
> + Sampler PUT /testme/123 => PUTs the
> + BeanShell script to clean up /tmp/requestbody-${discriminator}.xml
>
> The ${discriminator} variable should be unique per thread so that each
> thread can read/write to its own file.
>
> Do you think this is a valid approach or am I going to hit some walls?
> Is there another (better) approach?
>
> Regards,
> Karel
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org