You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@jmeter.apache.org by Hugh Hunter <Hu...@citysearch.com> on 2007/01/17 20:24:29 UTC
Sending HTTP requests at fixed rate
I've been using jmeter for a while now and have become frustrated with one
thing and one thing only: the (apparent) inability to send requests at a
fixed rate.
Correct me if I'm wrong, but the existing behavior seems to be that each
thread sends requests as fast as it can (ie, it sends a request and once it
has its response it sends again). What I'd like is to either let the
threading be dynamic or else create an excess of threads such that I can
send a HTTP requests to the server at a steady rate, thus allowing me to
monitor CPU, response times, etc from build to build with a test that is
more tightly controlled and consistent.
Anyone have any ideas?
Best,
--Hugh
--
Hugh Hunter
QA Engineer
P: 310.360.4321 F: 310.360.4449
E: hhunter@citysearch.com
Citysearch (Division of IAC/InterActiveCorp)
Leading local search, directory and media company
8833 W. Sunset Blvd.
West Hollywood, CA 90069
www.citysearch.com
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: Sending HTTP requests at fixed rate
Posted by sebb <se...@gmail.com>.
The throughput controller should help here.
S.
On 17/01/07, git <gi...@cubicalland.com> wrote:
> Hugh,
>
> I have had a similar issue. However, under careful investigation I came
> to the conclusion that sending requests at a fixed rate and fix number
> of concurrent requests is just about impossible. You can do one or the
> other but not both. The reason being that unless the server is very
> lightly loaded, sooner or later a request is going to take up more time
> than that allocated to it and thus you are either forced to reduce the
> rate (delay the next request) or increase the concurrency (increase the
> number of threads).
>
> If you are happy with a variable rate scenario, then using a sleep
> controller might do the trick. In general though, I think this is a bit
> Heisenberg like.
>
> Cheers
>
> AJ
>
> On Wed, 2007-01-17 at 11:24 -0800, Hugh Hunter wrote:
>
> > I've been using jmeter for a while now and have become frustrated with one
> > thing and one thing only: the (apparent) inability to send requests at a
> > fixed rate.
> >
> > Correct me if I'm wrong, but the existing behavior seems to be that each
> > thread sends requests as fast as it can (ie, it sends a request and once it
> > has its response it sends again). What I'd like is to either let the
> > threading be dynamic or else create an excess of threads such that I can
> > send a HTTP requests to the server at a steady rate, thus allowing me to
> > monitor CPU, response times, etc from build to build with a test that is
> > more tightly controlled and consistent.
> >
> > Anyone have any ideas?
> >
> > Best,
> >
> > --Hugh
> >
> > --
> >
> > Hugh Hunter
> > QA Engineer
> > P: 310.360.4321 F: 310.360.4449
> > E: hhunter@citysearch.com
> >
> > Citysearch (Division of IAC/InterActiveCorp)
> > Leading local search, directory and media company
> > 8833 W. Sunset Blvd.
> > West Hollywood, CA 90069
> > www.citysearch.com
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
> >
> >
> >
>
> www.cubicalland.com
> www.nerds-central.blogspot.com
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: Sending HTTP requests at fixed rate
Posted by git <gi...@cubicalland.com>.
Hugh,
I have had a similar issue. However, under careful investigation I came
to the conclusion that sending requests at a fixed rate and fix number
of concurrent requests is just about impossible. You can do one or the
other but not both. The reason being that unless the server is very
lightly loaded, sooner or later a request is going to take up more time
than that allocated to it and thus you are either forced to reduce the
rate (delay the next request) or increase the concurrency (increase the
number of threads).
If you are happy with a variable rate scenario, then using a sleep
controller might do the trick. In general though, I think this is a bit
Heisenberg like.
Cheers
AJ
On Wed, 2007-01-17 at 11:24 -0800, Hugh Hunter wrote:
> I've been using jmeter for a while now and have become frustrated with one
> thing and one thing only: the (apparent) inability to send requests at a
> fixed rate.
>
> Correct me if I'm wrong, but the existing behavior seems to be that each
> thread sends requests as fast as it can (ie, it sends a request and once it
> has its response it sends again). What I'd like is to either let the
> threading be dynamic or else create an excess of threads such that I can
> send a HTTP requests to the server at a steady rate, thus allowing me to
> monitor CPU, response times, etc from build to build with a test that is
> more tightly controlled and consistent.
>
> Anyone have any ideas?
>
> Best,
>
> --Hugh
>
> --
>
> Hugh Hunter
> QA Engineer
> P: 310.360.4321 F: 310.360.4449
> E: hhunter@citysearch.com
>
> Citysearch (Division of IAC/InterActiveCorp)
> Leading local search, directory and media company
> 8833 W. Sunset Blvd.
> West Hollywood, CA 90069
> www.citysearch.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>
>
>
www.cubicalland.com
www.nerds-central.blogspot.com