You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jmeter-dev@jakarta.apache.org by "BAZLEY, Sebastian" <Se...@london.sema.slb.com> on 2003/09/10 13:34:06 UTC
JMeter 2.0 - Sampler timimg change
A suggestion for JMeter 2.0:
Samplers at the moment have a timestamp which is set (e.g. by JMeterThread)
at the END of the sample. I think this is counter-intuitive (not sure if it
is mentioned in the documentation either).
Each sampler has to provide the elapsed time; they do this by calling
System.currentTimeMillis().
I would like to propose adding two methods to the SampleResult class.
These would be called by the Sampler just before starting its work and
immediately after the work has finished.
E.g. these could be called:
- sampleStarting
- sampleEnded
Advantages:
+ Samplers would be simpler - no need to fetch and save time locally
+ It would be very easy to use a higher-precision timer
+ Could easily swap to saving sampler start times instead of end-times
+ Could accumulate overall times multiple samples
Disadvantages:
- code would need to be updated, but this could be done gradually
(e.g. deprecate and later remove the exisiting methods)
- there must be some others ...?
SampleResult probably needs to be extended anyway to cope with storing
additional response data (e.g. response headers - see bug 23038
http://issues.apache.org/bugzilla/show_bug.cgi?id=23028 - Need Regex HTTP
Post Processor for HTTP Response Headers)
Comments?
--
The opinions expressed herein are my own, and are not necessarily endorsed
by my employer ...
Re: JMeter 2.0 - Sampler timimg change
Posted by peter lin <jm...@yahoo.com>.
I was just looking over the http samplers and I'm willing to help refactor the code to use a SampleResult factory. I'm also considering writing a custom sax parser to replace Tidy and make parsing the result a bit more efficient than creating an entire DOM document.
First I want to get a prototype monitor working, but I'm definitely interested in this line of thinking.
peter
mstover1@apache.org wrote:
I like the idea, but I've had slightly different thoughts on the matter. Instead of
putting this logic into the SampleResult class, how about a SampleResult factory
that can help Samplers instantiate, start, and end SampleResults. This could take
a lot of the burden off of Samplers to correctly populate results, and it wouldn't
mean making SampleResults intelligent.
I figure the factory could be either part of JMeterContext or available from it.
I also think we need a JMeterContext that is constant for a whole test run (not just
each thread). Perhaps eventually this factory could go there.
-Mike
On 10 Sep 2003 at 12:34, BAZLEY, Sebastian wrote:
> A suggestion for JMeter 2.0:
>
> Samplers at the moment have a timestamp which is set (e.g. by JMeterThread)
> at the END of the sample. I think this is counter-intuitive (not sure if it
> is mentioned in the documentation either).
>
> Each sampler has to provide the elapsed time; they do this by calling
> System.currentTimeMillis().
>
> I would like to propose adding two methods to the SampleResult class.
> These would be called by the Sampler just before starting its work and
> immediately after the work has finished.
>
> E.g. these could be called:
> - sampleStarting
> - sampleEnded
>
> Advantages:
> + Samplers would be simpler - no need to fetch and save time locally
> + It would be very easy to use a higher-precision timer
> + Could easily swap to saving sampler start times instead of end-times
> + Could accumulate overall times multiple samples
>
> Disadvantages:
> - code would need to be updated, but this could be done gradually
> (e.g. deprecate and later remove the exisiting methods)
> - there must be some others ...?
>
> SampleResult probably needs to be extended anyway to cope with storing
> additional response data (e.g. response headers - see bug 23038
> http://issues.apache.org/bugzilla/show_bug.cgi?id=23028 - Need Regex HTTP
> Post Processor for HTTP Response Headers)
>
> Comments?
>
> --
> The opinions expressed herein are my own, and are not necessarily endorsed
> by my employer ...
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
>
--
Michael Stover
mstover1@apache.org
Yahoo IM: mstover_ya
ICQ: 152975688
AIM: mstover777
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
---------------------------------
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
Re: JMeter 2.0 - Sampler timimg change
Posted by peter lin <jm...@yahoo.com>.
Another added benefit is the factory could reuse the objects to decrease the memory usage. On laptops this would be a welcome improvement :)
peter
mstover1@apache.org wrote:
I like the idea, but I've had slightly different thoughts on the matter. Instead of
putting this logic into the SampleResult class, how about a SampleResult factory
that can help Samplers instantiate, start, and end SampleResults. This could take
a lot of the burden off of Samplers to correctly populate results, and it wouldn't
mean making SampleResults intelligent.
I figure the factory could be either part of JMeterContext or available from it.
I also think we need a JMeterContext that is constant for a whole test run (not just
each thread). Perhaps eventually this factory could go there.
-Mike
On 10 Sep 2003 at 12:34, BAZLEY, Sebastian wrote:
> A suggestion for JMeter 2.0:
>
> Samplers at the moment have a timestamp which is set (e.g. by JMeterThread)
> at the END of the sample. I think this is counter-intuitive (not sure if it
> is mentioned in the documentation either).
>
> Each sampler has to provide the elapsed time; they do this by calling
> System.currentTimeMillis().
>
> I would like to propose adding two methods to the SampleResult class.
> These would be called by the Sampler just before starting its work and
> immediately after the work has finished.
>
> E.g. these could be called:
> - sampleStarting
> - sampleEnded
>
> Advantages:
> + Samplers would be simpler - no need to fetch and save time locally
> + It would be very easy to use a higher-precision timer
> + Could easily swap to saving sampler start times instead of end-times
> + Could accumulate overall times multiple samples
>
> Disadvantages:
> - code would need to be updated, but this could be done gradually
> (e.g. deprecate and later remove the exisiting methods)
> - there must be some others ...?
>
> SampleResult probably needs to be extended anyway to cope with storing
> additional response data (e.g. response headers - see bug 23038
> http://issues.apache.org/bugzilla/show_bug.cgi?id=23028 - Need Regex HTTP
> Post Processor for HTTP Response Headers)
>
> Comments?
>
> --
> The opinions expressed herein are my own, and are not necessarily endorsed
> by my employer ...
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
>
--
Michael Stover
mstover1@apache.org
Yahoo IM: mstover_ya
ICQ: 152975688
AIM: mstover777
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
---------------------------------
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
Re: JMeter 2.0 - Sampler timimg change
Posted by ms...@apache.org.
I like the idea, but I've had slightly different thoughts on the matter. Instead of
putting this logic into the SampleResult class, how about a SampleResult factory
that can help Samplers instantiate, start, and end SampleResults. This could take
a lot of the burden off of Samplers to correctly populate results, and it wouldn't
mean making SampleResults intelligent.
I figure the factory could be either part of JMeterContext or available from it.
I also think we need a JMeterContext that is constant for a whole test run (not just
each thread). Perhaps eventually this factory could go there.
-Mike
On 10 Sep 2003 at 12:34, BAZLEY, Sebastian wrote:
> A suggestion for JMeter 2.0:
>
> Samplers at the moment have a timestamp which is set (e.g. by JMeterThread)
> at the END of the sample. I think this is counter-intuitive (not sure if it
> is mentioned in the documentation either).
>
> Each sampler has to provide the elapsed time; they do this by calling
> System.currentTimeMillis().
>
> I would like to propose adding two methods to the SampleResult class.
> These would be called by the Sampler just before starting its work and
> immediately after the work has finished.
>
> E.g. these could be called:
> - sampleStarting
> - sampleEnded
>
> Advantages:
> + Samplers would be simpler - no need to fetch and save time locally
> + It would be very easy to use a higher-precision timer
> + Could easily swap to saving sampler start times instead of end-times
> + Could accumulate overall times multiple samples
>
> Disadvantages:
> - code would need to be updated, but this could be done gradually
> (e.g. deprecate and later remove the exisiting methods)
> - there must be some others ...?
>
> SampleResult probably needs to be extended anyway to cope with storing
> additional response data (e.g. response headers - see bug 23038
> http://issues.apache.org/bugzilla/show_bug.cgi?id=23028 - Need Regex HTTP
> Post Processor for HTTP Response Headers)
>
> Comments?
>
> --
> The opinions expressed herein are my own, and are not necessarily endorsed
> by my employer ...
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
>
--
Michael Stover
mstover1@apache.org
Yahoo IM: mstover_ya
ICQ: 152975688
AIM: mstover777