You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jmeter.apache.org by Philippe Mouawad <p....@ubik-ingenierie.com> on 2020/04/25 19:40:01 UTC

Precise Throughput Timer and rampup

Hello,

When you use Precise Throughput Timer how do you proceed to do this:

   - X req/h in first hour
   - 2X req/h in second hour
   - 3X req/h in third hour


I thought one way was to have a JSR223 PreProcessor like this:
------------------------------------------------------------------------
long startTime = vars["START.MS"].toLong();
long now = System.currentTimeMillis();
long diff = now -startTime;
if (diff >= 120000) {
   vars.put("THROUGHPUT", "3000");
} else if (diff >= 60000) {
   vars.put("THROUGHPUT", "2000");
} else {
    vars.put("THROUGHPUT", "1000");
}
------------------------------------------------------------------------

But it does not seem to work.

Vladimir, since you're the creator of this, how do you proceed in this case
?
Maybe there is room for improvement/simplification ?

-- 
Cordialement
Philippe M.
Ubik-Ingenierie

Re: Precise Throughput Timer and rampup

Posted by Antonio Gomes Rodrigues <ra...@gmail.com>.
Hi

Thanks to your analyze, I will stop mine

Maybe we need to remove this part from the documentation.

Variable load rate

Even though property values (e.g. throughput) can be defined via
expressions, it is recommended to keep the value more or less the same
through the test, as it takes time to recompute the new schedule to adapt
new values.




Le mar. 28 avr. 2020 à 08:55, Philippe Mouawad <
p.mouawad@ubik-ingenierie.com> a écrit :

> On Mon, Apr 27, 2020 at 9:33 PM Vladimir Sitnikov <
> sitnikov.vladimir@gmail.com> wrote:
>
> > >But it does not seem to work.
> >
> > There are two issues:
> > 1) You should use TESTSTART.MS rather than START.MS which is "JMeter
> start
> > time"
> >
> Yes, but I was using non gui to test, so they are very close to each other.
>
> 2) JMeter's execution model does not have room for "reducing timer delay on
> > the fly".
> > The current engine asks the timer for the "pause duration", then it
> pauses
> > the thread.
> > However, if the test code adjusts the delay on the fly, then the timer
> > can't reduce the thread delay.
> > AFAIK we can't use Thread.sleep in the timer code since JMeter would
> > probably charge it to the sampler duration.
> >
> > The ways to improve that is probably to make the timer aware of the
> desired
> > throughput ahead of time.
> >
> Yes, this would also make it more user friendly
>
>
> > Vladimir
> >
>
>
> --
> Cordialement
> Philippe M.
> Ubik-Ingenierie
>

Re: Precise Throughput Timer and rampup

Posted by Philippe Mouawad <p....@ubik-ingenierie.com>.
On Mon, Apr 27, 2020 at 9:33 PM Vladimir Sitnikov <
sitnikov.vladimir@gmail.com> wrote:

> >But it does not seem to work.
>
> There are two issues:
> 1) You should use TESTSTART.MS rather than START.MS which is "JMeter start
> time"
>
Yes, but I was using non gui to test, so they are very close to each other.

2) JMeter's execution model does not have room for "reducing timer delay on
> the fly".
> The current engine asks the timer for the "pause duration", then it pauses
> the thread.
> However, if the test code adjusts the delay on the fly, then the timer
> can't reduce the thread delay.
> AFAIK we can't use Thread.sleep in the timer code since JMeter would
> probably charge it to the sampler duration.
>
> The ways to improve that is probably to make the timer aware of the desired
> throughput ahead of time.
>
Yes, this would also make it more user friendly


> Vladimir
>


-- 
Cordialement
Philippe M.
Ubik-Ingenierie

Re: Precise Throughput Timer and rampup

Posted by Vladimir Sitnikov <si...@gmail.com>.
>But it does not seem to work.

There are two issues:
1) You should use TESTSTART.MS rather than START.MS which is "JMeter start
time"
2) JMeter's execution model does not have room for "reducing timer delay on
the fly".
The current engine asks the timer for the "pause duration", then it pauses
the thread.
However, if the test code adjusts the delay on the fly, then the timer
can't reduce the thread delay.
AFAIK we can't use Thread.sleep in the timer code since JMeter would
probably charge it to the sampler duration.

The ways to improve that is probably to make the timer aware of the desired
throughput ahead of time.

Vladimir

Re: Precise Throughput Timer and rampup

Posted by Philippe Mouawad <p....@ubik-ingenierie.com>.
No , little doubt but no bug I see at least

On Sat, Apr 25, 2020 at 9:49 PM Philippe Mouawad <
p.mouawad@ubik-ingenierie.com> wrote:

> There's a bug in my code, double checking
>
> On Sat, Apr 25, 2020 at 9:40 PM Philippe Mouawad <
> p.mouawad@ubik-ingenierie.com> wrote:
>
>> Hello,
>>
>> When you use Precise Throughput Timer how do you proceed to do this:
>>
>>    - X req/h in first hour
>>    - 2X req/h in second hour
>>    - 3X req/h in third hour
>>
>>
>> I thought one way was to have a JSR223 PreProcessor like this:
>> ------------------------------------------------------------------------
>> long startTime = vars["START.MS"].toLong();
>> long now = System.currentTimeMillis();
>> long diff = now -startTime;
>> if (diff >= 120000) {
>>    vars.put("THROUGHPUT", "3000");
>> } else if (diff >= 60000) {
>>    vars.put("THROUGHPUT", "2000");
>> } else {
>>     vars.put("THROUGHPUT", "1000");
>> }
>> ------------------------------------------------------------------------
>>
>> But it does not seem to work.
>>
>> Vladimir, since you're the creator of this, how do you proceed in this
>> case ?
>> Maybe there is room for improvement/simplification ?
>>
>> --
>> Cordialement
>> Philippe M.
>> Ubik-Ingenierie
>>
>>
>>
>>
>
> --
> Cordialement
> Philippe M.
> Ubik-Ingenierie
>


-- 
Cordialement
Philippe M.
Ubik-Ingenierie

Re: Precise Throughput Timer and rampup

Posted by Philippe Mouawad <p....@ubik-ingenierie.com>.
There's a bug in my code, double checking

On Sat, Apr 25, 2020 at 9:40 PM Philippe Mouawad <
p.mouawad@ubik-ingenierie.com> wrote:

> Hello,
>
> When you use Precise Throughput Timer how do you proceed to do this:
>
>    - X req/h in first hour
>    - 2X req/h in second hour
>    - 3X req/h in third hour
>
>
> I thought one way was to have a JSR223 PreProcessor like this:
> ------------------------------------------------------------------------
> long startTime = vars["START.MS"].toLong();
> long now = System.currentTimeMillis();
> long diff = now -startTime;
> if (diff >= 120000) {
>    vars.put("THROUGHPUT", "3000");
> } else if (diff >= 60000) {
>    vars.put("THROUGHPUT", "2000");
> } else {
>     vars.put("THROUGHPUT", "1000");
> }
> ------------------------------------------------------------------------
>
> But it does not seem to work.
>
> Vladimir, since you're the creator of this, how do you proceed in this
> case ?
> Maybe there is room for improvement/simplification ?
>
> --
> Cordialement
> Philippe M.
> Ubik-Ingenierie
>
>
>
>

-- 
Cordialement
Philippe M.
Ubik-Ingenierie