You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@jmeter.apache.org by "Nicholson, Brad (Toronto, ON, CA)" <bn...@hp.com> on 2011/09/14 17:14:49 UTC
Startup Cost on first operation
Hi,
I am using jmeter 2.5 and I am triggering my test via Ant and using the Jenkins Performance Plugin to display the data.
With each test I run, the first result has heavily inflated times (hundreds of milliseconds instead of a few). I'd like to avoid having such high numbers in the initial operation. Google seems to imply that this is paying the complication time of the jmeter script during this operation.
I can absorb the cost of this operation by adding a dummy operation at the start of the test, but I am wondering if there is a simpler/cleaner way of doing this?
Thanks,
Brad.
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
RE: Startup Cost on first operation
Posted by "Nicholson, Brad (Toronto, ON, CA)" <bn...@hp.com>.
> -----Original Message-----
> From: sebb [mailto:sebbaz@gmail.com]
> Sent: Wednesday, September 14, 2011 3:29 PM
> To: JMeter Users List
> Subject: Re: Startup Cost on first operation
> >>
> >> Are some of these URLs public?
> >>
> >> If so, can you create a Bugzilla issue and attach the JMX test
> script?
> >
> >
> > None of the URLS are public. I will see if I can get a test case
> together that does the same using a public URL though
I've reproduced this issue with a publically facing URL and filed Bug 51827 (with attached JMX file and output logs).
Thanks for your help. I'm happy to provide any further information or test patches if needed.
Brad.
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: Startup Cost on first operation
Posted by sebb <se...@gmail.com>.
On 14 September 2011 20:25, Nicholson, Brad (Toronto, ON, CA)
<bn...@hp.com> wrote:
>> -----Original Message-----
>> From: sebb [mailto:sebbaz@gmail.com]
>> Sent: Wednesday, September 14, 2011 3:12 PM
>> To: JMeter Users List
>> Subject: Re: Startup Cost on first operation
>>
>> On 14 September 2011 19:20, Nicholson, Brad (Toronto, ON, CA)
>> <bn...@hp.com> wrote:
>> >> -----Original Message-----
>> >> From: sebb [mailto:sebbaz@gmail.com]
>> >> Sent: Wednesday, September 14, 2011 1:29 PM
>> >> To: JMeter Users List
>> >> Subject: Re: Startup Cost on first operation
>> >>
>> >> On 14 September 2011 17:57, Nicholson, Brad (Toronto, ON, CA)
>> >> <bn...@hp.com> wrote:
>> >> >> -----Original Message-----
>> >> >> From: sebb [mailto:sebbaz@gmail.com]
>> >> >> Sent: Wednesday, September 14, 2011 11:27 AM
>> >> >> To: JMeter Users List
>> >> >> Subject: Re: Startup Cost on first operation
>> >> >>
>> >> >> On 14 September 2011 16:14, Nicholson, Brad (Toronto, ON, CA)
>> >> >> <bn...@hp.com> wrote:
>> >> >> > Hi,
>> >> >> >
>> >> >> > I am using jmeter 2.5 and I am triggering my test via Ant and
>> >> using
>> >> >> the Jenkins Performance Plugin to display the data.
>> >> >> >
>> >> >> > With each test I run, the first result has heavily inflated
>> times
>> >> >> (hundreds of milliseconds instead of a few). I'd like to avoid
>> >> having
>> >> >> such high numbers in the initial operation. Google seems to
>> imply
>> >> that
>> >> >> this is paying the complication time of the jmeter script during
>> >> this
>> >> >> operation.
>> >> >>
>> >> >> Do you mean compilation time?
>> >> >
>> >> > Sorry, yes - I mean compilation time.
>> >> >
>> >> >
>> >> >> If so, that is done before the sample is started; sample times
>> >> include
>> >> >> only the time needed to perform the sample.
>> >> >>
>> >> >> > I can absorb the cost of this operation by adding a dummy
>> >> operation
>> >> >> at the start of the test, but I am wondering if there is a
>> >> >> simpler/cleaner way of doing this?
>> >> >>
>> >> >> That should not be necessary; there must be something else
>> happening
>> >> >> here.
>> >> >>
>> >> >> Try using a Java sampler. Does the first sample take longer than
>> the
>> >> >> next?
>> >> >
>> >> > No - they are fairly uniform
>> >> >
>> >> >> What happens if you add a dummy before that?
>> >> >
>> >> > Dummy request takes a higher startup time, no change the Java
>> >> request.
>> >> >
>> >> > All my requests (including the dummy request) are HTTP Request's
>> and
>> >> are connecting via https.
>> >>
>> >> https is much more expensive in connection setup
>> >>
>> >> >> Are you sure that the Jenkins Performance plugin is measuring
>> >> samples,
>> >> >> and not JMeter startup time?
>> >> >
>> >> > I'm sure it's not. I've confirmed by checking the raw output
>> files
>> >> written by Jmeter. To completely eliminate other moving pieces,
>> I've
>> >> re-run the test repeatedly directly from Jmeter and I see the same
>> >> behavior.
>> >>
>> >> The only thing I can think of that might be causing the problem is
>> the
>> >> connection setup.
>> >> First time JMeter init for a connection will be slightly slower, but
>> >> should barely be noticeable; it will be the external stuff that
>> takes
>> >> the most time.
>> >> And that will apply to browsers as well.
>> >>
>> >> Does the additional time apply to other target hosts?
>> >
>> > Yes - I've run it against a number of different hosts and the first
>> request is always significantly higher.
>> >
>> >
>> >> Which sampler are you using?
>> >
>> > HTTP Request
>>
>> Yes, but which implementation?
>> Java, HttpClient3.1, HttpClient4?
>
> How can I tell? I built the test with the Jmeter 2.4 GUI and added them with Add->Sampler->HTTP Request
That's the Java version, the other one is called
HTTP Request HTTPClient.
>
>> >> Are you using Keep-Alive?
>> >
>> > Yes
>> >
>> >> If you switch it off, each sampler will have to create the
>> connection
>> >> anew, so I would expect all the samples to take longer.
>> >
>> > I tried with keep alive off and there is no statistically interesting
>> difference. First operation is always around 600ms, all subsequent run
>> between 8ms to 25ms. It's the same for both keep-alive enabled and
>> disabled. I've tested with a variety of URL's btw, and the result is
>> always the same.
>>
>> Are some of these URLs public?
>>
>> If so, can you create a Bugzilla issue and attach the JMX test script?
>
>
> None of the URLS are public. I will see if I can get a test case together that does the same using a public URL though.
>
> Thanks,
> Brad.
>
> ---------------------------------------------------------------------
> 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: Startup Cost on first operation
Posted by "Nicholson, Brad (Toronto, ON, CA)" <bn...@hp.com>.
> -----Original Message-----
> From: sebb [mailto:sebbaz@gmail.com]
> Sent: Wednesday, September 14, 2011 3:12 PM
> To: JMeter Users List
> Subject: Re: Startup Cost on first operation
>
> On 14 September 2011 19:20, Nicholson, Brad (Toronto, ON, CA)
> <bn...@hp.com> wrote:
> >> -----Original Message-----
> >> From: sebb [mailto:sebbaz@gmail.com]
> >> Sent: Wednesday, September 14, 2011 1:29 PM
> >> To: JMeter Users List
> >> Subject: Re: Startup Cost on first operation
> >>
> >> On 14 September 2011 17:57, Nicholson, Brad (Toronto, ON, CA)
> >> <bn...@hp.com> wrote:
> >> >> -----Original Message-----
> >> >> From: sebb [mailto:sebbaz@gmail.com]
> >> >> Sent: Wednesday, September 14, 2011 11:27 AM
> >> >> To: JMeter Users List
> >> >> Subject: Re: Startup Cost on first operation
> >> >>
> >> >> On 14 September 2011 16:14, Nicholson, Brad (Toronto, ON, CA)
> >> >> <bn...@hp.com> wrote:
> >> >> > Hi,
> >> >> >
> >> >> > I am using jmeter 2.5 and I am triggering my test via Ant and
> >> using
> >> >> the Jenkins Performance Plugin to display the data.
> >> >> >
> >> >> > With each test I run, the first result has heavily inflated
> times
> >> >> (hundreds of milliseconds instead of a few). I'd like to avoid
> >> having
> >> >> such high numbers in the initial operation. Google seems to
> imply
> >> that
> >> >> this is paying the complication time of the jmeter script during
> >> this
> >> >> operation.
> >> >>
> >> >> Do you mean compilation time?
> >> >
> >> > Sorry, yes - I mean compilation time.
> >> >
> >> >
> >> >> If so, that is done before the sample is started; sample times
> >> include
> >> >> only the time needed to perform the sample.
> >> >>
> >> >> > I can absorb the cost of this operation by adding a dummy
> >> operation
> >> >> at the start of the test, but I am wondering if there is a
> >> >> simpler/cleaner way of doing this?
> >> >>
> >> >> That should not be necessary; there must be something else
> happening
> >> >> here.
> >> >>
> >> >> Try using a Java sampler. Does the first sample take longer than
> the
> >> >> next?
> >> >
> >> > No - they are fairly uniform
> >> >
> >> >> What happens if you add a dummy before that?
> >> >
> >> > Dummy request takes a higher startup time, no change the Java
> >> request.
> >> >
> >> > All my requests (including the dummy request) are HTTP Request's
> and
> >> are connecting via https.
> >>
> >> https is much more expensive in connection setup
> >>
> >> >> Are you sure that the Jenkins Performance plugin is measuring
> >> samples,
> >> >> and not JMeter startup time?
> >> >
> >> > I'm sure it's not. I've confirmed by checking the raw output
> files
> >> written by Jmeter. To completely eliminate other moving pieces,
> I've
> >> re-run the test repeatedly directly from Jmeter and I see the same
> >> behavior.
> >>
> >> The only thing I can think of that might be causing the problem is
> the
> >> connection setup.
> >> First time JMeter init for a connection will be slightly slower, but
> >> should barely be noticeable; it will be the external stuff that
> takes
> >> the most time.
> >> And that will apply to browsers as well.
> >>
> >> Does the additional time apply to other target hosts?
> >
> > Yes - I've run it against a number of different hosts and the first
> request is always significantly higher.
> >
> >
> >> Which sampler are you using?
> >
> > HTTP Request
>
> Yes, but which implementation?
> Java, HttpClient3.1, HttpClient4?
How can I tell? I built the test with the Jmeter 2.4 GUI and added them with Add->Sampler->HTTP Request
> >> Are you using Keep-Alive?
> >
> > Yes
> >
> >> If you switch it off, each sampler will have to create the
> connection
> >> anew, so I would expect all the samples to take longer.
> >
> > I tried with keep alive off and there is no statistically interesting
> difference. First operation is always around 600ms, all subsequent run
> between 8ms to 25ms. It's the same for both keep-alive enabled and
> disabled. I've tested with a variety of URL's btw, and the result is
> always the same.
>
> Are some of these URLs public?
>
> If so, can you create a Bugzilla issue and attach the JMX test script?
None of the URLS are public. I will see if I can get a test case together that does the same using a public URL though.
Thanks,
Brad.
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: Startup Cost on first operation
Posted by sebb <se...@gmail.com>.
On 14 September 2011 19:20, Nicholson, Brad (Toronto, ON, CA)
<bn...@hp.com> wrote:
>> -----Original Message-----
>> From: sebb [mailto:sebbaz@gmail.com]
>> Sent: Wednesday, September 14, 2011 1:29 PM
>> To: JMeter Users List
>> Subject: Re: Startup Cost on first operation
>>
>> On 14 September 2011 17:57, Nicholson, Brad (Toronto, ON, CA)
>> <bn...@hp.com> wrote:
>> >> -----Original Message-----
>> >> From: sebb [mailto:sebbaz@gmail.com]
>> >> Sent: Wednesday, September 14, 2011 11:27 AM
>> >> To: JMeter Users List
>> >> Subject: Re: Startup Cost on first operation
>> >>
>> >> On 14 September 2011 16:14, Nicholson, Brad (Toronto, ON, CA)
>> >> <bn...@hp.com> wrote:
>> >> > Hi,
>> >> >
>> >> > I am using jmeter 2.5 and I am triggering my test via Ant and
>> using
>> >> the Jenkins Performance Plugin to display the data.
>> >> >
>> >> > With each test I run, the first result has heavily inflated times
>> >> (hundreds of milliseconds instead of a few). I'd like to avoid
>> having
>> >> such high numbers in the initial operation. Google seems to imply
>> that
>> >> this is paying the complication time of the jmeter script during
>> this
>> >> operation.
>> >>
>> >> Do you mean compilation time?
>> >
>> > Sorry, yes - I mean compilation time.
>> >
>> >
>> >> If so, that is done before the sample is started; sample times
>> include
>> >> only the time needed to perform the sample.
>> >>
>> >> > I can absorb the cost of this operation by adding a dummy
>> operation
>> >> at the start of the test, but I am wondering if there is a
>> >> simpler/cleaner way of doing this?
>> >>
>> >> That should not be necessary; there must be something else happening
>> >> here.
>> >>
>> >> Try using a Java sampler. Does the first sample take longer than the
>> >> next?
>> >
>> > No - they are fairly uniform
>> >
>> >> What happens if you add a dummy before that?
>> >
>> > Dummy request takes a higher startup time, no change the Java
>> request.
>> >
>> > All my requests (including the dummy request) are HTTP Request's and
>> are connecting via https.
>>
>> https is much more expensive in connection setup
>>
>> >> Are you sure that the Jenkins Performance plugin is measuring
>> samples,
>> >> and not JMeter startup time?
>> >
>> > I'm sure it's not. I've confirmed by checking the raw output files
>> written by Jmeter. To completely eliminate other moving pieces, I've
>> re-run the test repeatedly directly from Jmeter and I see the same
>> behavior.
>>
>> The only thing I can think of that might be causing the problem is the
>> connection setup.
>> First time JMeter init for a connection will be slightly slower, but
>> should barely be noticeable; it will be the external stuff that takes
>> the most time.
>> And that will apply to browsers as well.
>>
>> Does the additional time apply to other target hosts?
>
> Yes - I've run it against a number of different hosts and the first request is always significantly higher.
>
>
>> Which sampler are you using?
>
> HTTP Request
Yes, but which implementation?
Java, HttpClient3.1, HttpClient4?
>> Are you using Keep-Alive?
>
> Yes
>
>> If you switch it off, each sampler will have to create the connection
>> anew, so I would expect all the samples to take longer.
>
> I tried with keep alive off and there is no statistically interesting difference. First operation is always around 600ms, all subsequent run between 8ms to 25ms. It's the same for both keep-alive enabled and disabled. I've tested with a variety of URL's btw, and the result is always the same.
Are some of these URLs public?
If so, can you create a Bugzilla issue and attach the JMX test script?
>> AFAIK, JMeter itself does not do any expensive first-time init for
>> either https or http (obviously if it does that should be fixed to
>> exclude that time).
>> However connections do have a setup overhead, which will apply to any
>> application, including browsers, and need to be included in the JMeter
>> sample time.
>
> There seems to be something in Jmeter causing this. I tried testing some of the same URL's with Apache Benchmark and I pay no startup cost on those tests.
Or it could be Java.
AFAIK AB is C code.
> Brad.
>
> ---------------------------------------------------------------------
> 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: Startup Cost on first operation
Posted by "Nicholson, Brad (Toronto, ON, CA)" <bn...@hp.com>.
> -----Original Message-----
> From: sebb [mailto:sebbaz@gmail.com]
> Sent: Wednesday, September 14, 2011 1:29 PM
> To: JMeter Users List
> Subject: Re: Startup Cost on first operation
>
> On 14 September 2011 17:57, Nicholson, Brad (Toronto, ON, CA)
> <bn...@hp.com> wrote:
> >> -----Original Message-----
> >> From: sebb [mailto:sebbaz@gmail.com]
> >> Sent: Wednesday, September 14, 2011 11:27 AM
> >> To: JMeter Users List
> >> Subject: Re: Startup Cost on first operation
> >>
> >> On 14 September 2011 16:14, Nicholson, Brad (Toronto, ON, CA)
> >> <bn...@hp.com> wrote:
> >> > Hi,
> >> >
> >> > I am using jmeter 2.5 and I am triggering my test via Ant and
> using
> >> the Jenkins Performance Plugin to display the data.
> >> >
> >> > With each test I run, the first result has heavily inflated times
> >> (hundreds of milliseconds instead of a few). I'd like to avoid
> having
> >> such high numbers in the initial operation. Google seems to imply
> that
> >> this is paying the complication time of the jmeter script during
> this
> >> operation.
> >>
> >> Do you mean compilation time?
> >
> > Sorry, yes - I mean compilation time.
> >
> >
> >> If so, that is done before the sample is started; sample times
> include
> >> only the time needed to perform the sample.
> >>
> >> > I can absorb the cost of this operation by adding a dummy
> operation
> >> at the start of the test, but I am wondering if there is a
> >> simpler/cleaner way of doing this?
> >>
> >> That should not be necessary; there must be something else happening
> >> here.
> >>
> >> Try using a Java sampler. Does the first sample take longer than the
> >> next?
> >
> > No - they are fairly uniform
> >
> >> What happens if you add a dummy before that?
> >
> > Dummy request takes a higher startup time, no change the Java
> request.
> >
> > All my requests (including the dummy request) are HTTP Request's and
> are connecting via https.
>
> https is much more expensive in connection setup
>
> >> Are you sure that the Jenkins Performance plugin is measuring
> samples,
> >> and not JMeter startup time?
> >
> > I'm sure it's not. I've confirmed by checking the raw output files
> written by Jmeter. To completely eliminate other moving pieces, I've
> re-run the test repeatedly directly from Jmeter and I see the same
> behavior.
>
> The only thing I can think of that might be causing the problem is the
> connection setup.
> First time JMeter init for a connection will be slightly slower, but
> should barely be noticeable; it will be the external stuff that takes
> the most time.
> And that will apply to browsers as well.
>
> Does the additional time apply to other target hosts?
Yes - I've run it against a number of different hosts and the first request is always significantly higher.
> Which sampler are you using?
HTTP Request
> Are you using Keep-Alive?
Yes
> If you switch it off, each sampler will have to create the connection
> anew, so I would expect all the samples to take longer.
I tried with keep alive off and there is no statistically interesting difference. First operation is always around 600ms, all subsequent run between 8ms to 25ms. It's the same for both keep-alive enabled and disabled. I've tested with a variety of URL's btw, and the result is always the same.
> AFAIK, JMeter itself does not do any expensive first-time init for
> either https or http (obviously if it does that should be fixed to
> exclude that time).
> However connections do have a setup overhead, which will apply to any
> application, including browsers, and need to be included in the JMeter
> sample time.
There seems to be something in Jmeter causing this. I tried testing some of the same URL's with Apache Benchmark and I pay no startup cost on those tests.
Brad.
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: Startup Cost on first operation
Posted by sebb <se...@gmail.com>.
On 14 September 2011 17:57, Nicholson, Brad (Toronto, ON, CA)
<bn...@hp.com> wrote:
>> -----Original Message-----
>> From: sebb [mailto:sebbaz@gmail.com]
>> Sent: Wednesday, September 14, 2011 11:27 AM
>> To: JMeter Users List
>> Subject: Re: Startup Cost on first operation
>>
>> On 14 September 2011 16:14, Nicholson, Brad (Toronto, ON, CA)
>> <bn...@hp.com> wrote:
>> > Hi,
>> >
>> > I am using jmeter 2.5 and I am triggering my test via Ant and using
>> the Jenkins Performance Plugin to display the data.
>> >
>> > With each test I run, the first result has heavily inflated times
>> (hundreds of milliseconds instead of a few). I'd like to avoid having
>> such high numbers in the initial operation. Google seems to imply that
>> this is paying the complication time of the jmeter script during this
>> operation.
>>
>> Do you mean compilation time?
>
> Sorry, yes - I mean compilation time.
>
>
>> If so, that is done before the sample is started; sample times include
>> only the time needed to perform the sample.
>>
>> > I can absorb the cost of this operation by adding a dummy operation
>> at the start of the test, but I am wondering if there is a
>> simpler/cleaner way of doing this?
>>
>> That should not be necessary; there must be something else happening
>> here.
>>
>> Try using a Java sampler. Does the first sample take longer than the
>> next?
>
> No - they are fairly uniform
>
>> What happens if you add a dummy before that?
>
> Dummy request takes a higher startup time, no change the Java request.
>
> All my requests (including the dummy request) are HTTP Request's and are connecting via https.
https is much more expensive in connection setup
>> Are you sure that the Jenkins Performance plugin is measuring samples,
>> and not JMeter startup time?
>
> I'm sure it's not. I've confirmed by checking the raw output files written by Jmeter. To completely eliminate other moving pieces, I've re-run the test repeatedly directly from Jmeter and I see the same behavior.
The only thing I can think of that might be causing the problem is the
connection setup.
First time JMeter init for a connection will be slightly slower, but
should barely be noticeable; it will be the external stuff that takes
the most time.
And that will apply to browsers as well.
Does the additional time apply to other target hosts?
Which sampler are you using?
Are you using Keep-Alive?
If you switch it off, each sampler will have to create the connection
anew, so I would expect all the samples to take longer.
AFAIK, JMeter itself does not do any expensive first-time init for
either https or http (obviously if it does that should be fixed to
exclude that time).
However connections do have a setup overhead, which will apply to any
application, including browsers, and need to be included in the JMeter
sample time.
> Brad.
>
>
> ---------------------------------------------------------------------
> 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: Startup Cost on first operation
Posted by "Nicholson, Brad (Toronto, ON, CA)" <bn...@hp.com>.
> -----Original Message-----
> From: sebb [mailto:sebbaz@gmail.com]
> Sent: Wednesday, September 14, 2011 11:27 AM
> To: JMeter Users List
> Subject: Re: Startup Cost on first operation
>
> On 14 September 2011 16:14, Nicholson, Brad (Toronto, ON, CA)
> <bn...@hp.com> wrote:
> > Hi,
> >
> > I am using jmeter 2.5 and I am triggering my test via Ant and using
> the Jenkins Performance Plugin to display the data.
> >
> > With each test I run, the first result has heavily inflated times
> (hundreds of milliseconds instead of a few). I'd like to avoid having
> such high numbers in the initial operation. Google seems to imply that
> this is paying the complication time of the jmeter script during this
> operation.
>
> Do you mean compilation time?
Sorry, yes - I mean compilation time.
> If so, that is done before the sample is started; sample times include
> only the time needed to perform the sample.
>
> > I can absorb the cost of this operation by adding a dummy operation
> at the start of the test, but I am wondering if there is a
> simpler/cleaner way of doing this?
>
> That should not be necessary; there must be something else happening
> here.
>
> Try using a Java sampler. Does the first sample take longer than the
> next?
No - they are fairly uniform
> What happens if you add a dummy before that?
Dummy request takes a higher startup time, no change the Java request.
All my requests (including the dummy request) are HTTP Request's and are connecting via https.
> Are you sure that the Jenkins Performance plugin is measuring samples,
> and not JMeter startup time?
I'm sure it's not. I've confirmed by checking the raw output files written by Jmeter. To completely eliminate other moving pieces, I've re-run the test repeatedly directly from Jmeter and I see the same behavior.
Brad.
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: Startup Cost on first operation
Posted by sebb <se...@gmail.com>.
On 14 September 2011 16:14, Nicholson, Brad (Toronto, ON, CA)
<bn...@hp.com> wrote:
> Hi,
>
> I am using jmeter 2.5 and I am triggering my test via Ant and using the Jenkins Performance Plugin to display the data.
>
> With each test I run, the first result has heavily inflated times (hundreds of milliseconds instead of a few). I'd like to avoid having such high numbers in the initial operation. Google seems to imply that this is paying the complication time of the jmeter script during this operation.
Do you mean compilation time?
If so, that is done before the sample is started; sample times include
only the time needed to perform the sample.
> I can absorb the cost of this operation by adding a dummy operation at the start of the test, but I am wondering if there is a simpler/cleaner way of doing this?
That should not be necessary; there must be something else happening here.
Try using a Java sampler. Does the first sample take longer than the next?
What happens if you add a dummy before that?
Are you sure that the Jenkins Performance plugin is measuring samples,
and not JMeter startup time?
> Thanks,
> Brad.
>
> ---------------------------------------------------------------------
> 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