You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jmeter.apache.org by Andrey Pokhilko <ap...@ya.ru> on 2015/04/15 11:32:30 UTC
Post-Sampler Timers
Hi,
When I try to introduce JMeter to new people, I frequently see them
confused with our way to set "think times" before request. Especially
those who used to use some other testing tools, where think-time is
_after_ request.
I personally think that think-time should be made after request, because
its duration depends on the results of the request. If you have got long
text as a result of your request, you supposed to spend some time
reading it. If you have short error message, you supposed to do your
next request much faster. The _delay_ time before request still makes
sense, because it allows manipulating throughput and synchronize requests.
I would like to contribute to JMeter following changes:
1. Add a property for Timers, marking them as "pre-sampler" or
"post-sampler" timers
2. Modify thread execution flow to call pre-timers and post-timers
accordingly
3. Modify timers UIs where it is reasonable, adding radio button to
change timer mode
Any thoughts/objections on this?
--
Andrey Pokhilko
Re: Post-Sampler Timers
Posted by Vladimir Sitnikov <si...@gmail.com>.
Andrey>why people search for problems instead of opportunities :)
Andrey>Any thoughts/objections on this?
Well, it was you who wanted objections.
In two words: I agree with Shmuel, I do not see much value.
See in the end of the mail my vision on how the need for post-samplers
can be fixed.
>> Users assume that timers are executed at the place where they appear
>> in test plan.
> This is common problem with all JMeter components, like config items and
> post-processors. I have nothing to do with this.
We all should care not to make the UI and the core an inconsistent
combination of features here and there.
> So you can add two timers, one for pre-sample and one for post-sample.
And there it goes. I wonder how often "post-sample" timer is actually required.
I agree the optimization (i.e. optimize user clicks in UI to produce
the jmx) should be for the most common case, however I can't tell if
current workarounds of "adding timer to the next sampler" or "adding
dummy sampler with timer" are much worse than incompatibility of jmx
plans we'd get with post timers.
Test plan with post timers would require a specific JMeter version,
thus it may produce catch 22: "you want to downgrade JMeter to avoid
some bug, but you can't since old JMeter does not load your jmx".
Let me try a bit different view:
Currently you tie low level representation (particular samplers,
timers) with the UI.
In other words, you do not like "adding dummy test action" just
because it is messy in the UI. Is it the only reason?
What if JMeter UI could display higher level concepts, while still
using simple and dumb test actions/timers behind the scenes?
That would allow nice UI and backward-and-forward-compatible jmx
format while keeping core test plan elements simple. Think of java
source vs java byte code.
For instance, in the particular case JMeter UI could display the timer
in question as "post timer" somehow, and when it comes to store that
plan in jmx, JMeter would convert "post timer" to a dummy test action
with a sampler inside.
The core is happy to execute the plan unmodified, while you get "nice UI".
This scales as proven by java language evolution when new language
features are smoothly integrated with old binaries.
As a first step, "macros" can be implemented.
For instance, you click "add think timer" and JMeter adds "Test
Action"+"Think Timer" in a single shot.
I think it would cover most of the current needs, while keeping jmx
and core compatible.
Later we can teach the UI to fold-unfold macros.
Vladimir
Re: Post-Sampler Timers
Posted by Andrey Pokhilko <ap...@ya.ru>.
My comments are below. I wonder why I hear so many objections, why
people search for problems instead of opportunities :)
Andrey Pokhilko
On 04/15/2015 08:04 PM, Vladimir Sitnikov wrote:
> Sorry for long posts.
> I think we hit just a tip of the iceberg.
>
> From my experience, the most important problem of timers is "timers
> are listeners, not samplers".
> Users assume that timers are executed at the place where they appear
> in test plan.
> It takes a while to realize that timers are inherited to all the
> siblings' child samplers.
>
> Not sure how to fix that though. Some warning should probably be
> displayed if a timer has more than one siblings' child (~ "the timer
> is probably misplaced").
This is common problem with all JMeter components, like config items and
post-processors. I have nothing to do with this.
>> There is no reasons not to scale
> I mean not "performance-wise" scalability, but code
> maintenance/user-experience scalability.
> The question is what efforts will consume the approach of making
> timers more complex.
>
>> Synchronizing timers will be pre-sample always
> Well, there might be an interesting pattern to synchronize in
> post-sample, so questions might appear "why my timer does not support
> pre-post mode".
No problem, we can add toggle to any timer.
>> Timer either pre-sample or post-sample, there is no "mid-sample"
> timers.
>
> I mean orthogonal features as well.
> There might be "pre _and_ post" delays at the same time.
So you can add two timers, one for pre-sample and one for post-sample.
Makes sense to manage these timers separately, since they reflect delays
of different nature.
> For instance, I want "test reproducibility" feature.
> So I could replay the same delays in different test executions (that
> is using some pre-defined random seed).
>
> I have that feature in my own timer and it proved to be very useful to
> compare different test executions.
> If the same feature appears in public build, there is a question how
> "random seed" should be specified for timers in a consistent way.
>
>> The behavior will be consistent and timer will be called after post-processor
> I mean another kind of consistency:
> 1) Currently JMeter has separate sets of "pre processors" and "post
> processors". You can't pick "mode of processor" in the processor's UI.
> 2) For timers you suggest a bit different approach: single timer while
> pre-post mode to be configured in the UI.
> That is what I call inconsistent user experience.
Good point, but I don't think this toggle worth introducing whole new
class of components. Pre/Post processors have different objects they
manipulate (next sampler and last sample result). Timers have no
difference except moment of their call. And duplicating all timers in
two groups looks not graceful idea.
>> Subtracting sleep time from total transaction time is a
>> question for Transaction Controller and out of scope for this topic
> It should be in scope.
> Did you verify that your approach does not breaks TC logic?
> You shouldn't deliver a feature that does not play well with basic
> functionality like TC.
> Otherwise users would be very confused.
>
> Vladimir
Re: Post-Sampler Timers
Posted by Vladimir Sitnikov <si...@gmail.com>.
Sorry for long posts.
I think we hit just a tip of the iceberg.
>From my experience, the most important problem of timers is "timers
are listeners, not samplers".
Users assume that timers are executed at the place where they appear
in test plan.
It takes a while to realize that timers are inherited to all the
siblings' child samplers.
Not sure how to fix that though. Some warning should probably be
displayed if a timer has more than one siblings' child (~ "the timer
is probably misplaced").
> There is no reasons not to scale
I mean not "performance-wise" scalability, but code
maintenance/user-experience scalability.
The question is what efforts will consume the approach of making
timers more complex.
> Synchronizing timers will be pre-sample always
Well, there might be an interesting pattern to synchronize in
post-sample, so questions might appear "why my timer does not support
pre-post mode".
>Timer either pre-sample or post-sample, there is no "mid-sample"
timers.
I mean orthogonal features as well.
There might be "pre _and_ post" delays at the same time.
For instance, I want "test reproducibility" feature.
So I could replay the same delays in different test executions (that
is using some pre-defined random seed).
I have that feature in my own timer and it proved to be very useful to
compare different test executions.
If the same feature appears in public build, there is a question how
"random seed" should be specified for timers in a consistent way.
>The behavior will be consistent and timer will be called after post-processor
I mean another kind of consistency:
1) Currently JMeter has separate sets of "pre processors" and "post
processors". You can't pick "mode of processor" in the processor's UI.
2) For timers you suggest a bit different approach: single timer while
pre-post mode to be configured in the UI.
That is what I call inconsistent user experience.
> Subtracting sleep time from total transaction time is a
> question for Transaction Controller and out of scope for this topic
It should be in scope.
Did you verify that your approach does not breaks TC logic?
You shouldn't deliver a feature that does not play well with basic
functionality like TC.
Otherwise users would be very confused.
Vladimir
Re: Post-Sampler Timers
Posted by Andrey Pokhilko <ap...@ya.ru>.
There is no reasons not to scale. The behavior will be consistent and
timer will be called after post-processor, allowing to set some variable
based on sample result and use that variable as think-time delay.
Not each of the timers would need to support the toggle (e.g. Constant
Throughput and Synchronizing timers will be pre-sample always), and by
default any timer would be "pre-sample" to be compatible with previous
versions of JMeter scripts.
I see no "next" feature that will lead to exponential growth of logic.
Timer either pre-sample or post-sample, there is no "mid-sample"
timers... Again, for each timer we can decide if it will offer UI to
change its role or not.
Timer will not affect sampler time unless used within Transaction
controller, so this aspect will also be consistent with current
behavior. Subtracting sleep time from total transaction time is a
question for Transaction Controller and out of scope for this topic.
Andrey Pokhilko
On 04/15/2015 05:54 PM, Vladimir Sitnikov wrote:
>> 3. Modify timers UIs where it is reasonable, adding radio button to
> change timer mode
>
> Will that scale?
> Will that be consistent with pre/post processors?
>
> Each and every timer would have to support "pre-post mode".
> Suppose you add another feature, then it will be an exponential number
> of combinations in timer UIs.
>
> Well, there could probably be "post timer" that has access to the
> sampler result and adjust sleep duration accordingly (e.g. sleep 1sec
> for each 10KiB or response).
>
> I wonder if "seeping after sampler execution" would break response
> time reporting.
> Especially, for "transaction controller" that is known to have obscure code.
>
> Vladimir
Re: Post-Sampler Timers
Posted by Vladimir Sitnikov <si...@gmail.com>.
> 3. Modify timers UIs where it is reasonable, adding radio button to
change timer mode
Will that scale?
Will that be consistent with pre/post processors?
Each and every timer would have to support "pre-post mode".
Suppose you add another feature, then it will be an exponential number
of combinations in timer UIs.
Well, there could probably be "post timer" that has access to the
sampler result and adjust sleep duration accordingly (e.g. sleep 1sec
for each 10KiB or response).
I wonder if "seeping after sampler execution" would break response
time reporting.
Especially, for "transaction controller" that is known to have obscure code.
Vladimir
Re: Post-Sampler Timers
Posted by sebb <se...@gmail.com>.
On 17 April 2015 at 11:59, Vladimir Sitnikov
<si...@gmail.com> wrote:
>> The macro idea is neat, but I think it will cause user confusion if
>> the display shows the raw constituents of the macro.
>
> I think it would be nice to have fold/unfold display.
> For instance, something like how IDEA folds boilerplate code:
> http://blog.jetbrains.com/idea/2009/03/closure-folding-in-intellij-idea-9-maia/
That would help, but I still think it has the potential to cause confusion.
It also adds to the work needed to implement the feature.
> Vladimir
Re: Post-Sampler Timers
Posted by Vladimir Sitnikov <si...@gmail.com>.
> The macro idea is neat, but I think it will cause user confusion if
> the display shows the raw constituents of the macro.
I think it would be nice to have fold/unfold display.
For instance, something like how IDEA folds boilerplate code:
http://blog.jetbrains.com/idea/2009/03/closure-folding-in-intellij-idea-9-maia/
Vladimir
Re: Post-Sampler Timers
Posted by sebb <se...@gmail.com>.
Note: for fixed time delays, the Test Action can be used without the
need to add a child Timer.
Potentially the Test Action sampler can provide variable delays by use
of a suitable function for the delay.
The macro idea is neat, but I think it will cause user confusion if
the display shows the raw constituents of the macro.
On 16 April 2015 at 12:31, Vladimir Sitnikov
<si...@gmail.com> wrote:
>> I find the Macros Idea of Vladimir interesting if I understand it well.
>> It could be extended to make macros configurable and thus users could
>> configure their own macros, it is a much wider scope than current thread.
>> It deserves a Bugzilla.
>>
>> @Vladimir did I understand correctly your idea ?
>
> That's correct.
>
> Vladimir
Re: Post-Sampler Timers
Posted by Vladimir Sitnikov <si...@gmail.com>.
> I find the Macros Idea of Vladimir interesting if I understand it well.
> It could be extended to make macros configurable and thus users could
> configure their own macros, it is a much wider scope than current thread.
> It deserves a Bugzilla.
>
> @Vladimir did I understand correctly your idea ?
That's correct.
Vladimir
Re: Post-Sampler Timers
Posted by Philippe Mouawad <ph...@gmail.com>.
Hi,
I find the Macros Idea of Vladimir interesting if I understand it well.
It could be extended to make macros configurable and thus users could
configure their own macros, it is a much wider scope than current thread.
It deserves a Bugzilla.
@Vladimir did I understand correctly your idea ?
@Andrey:
1/ I find it cool that you get so much feedback, it means your proposal is
interesting :-) and it is great to have feedback from end users before we
create / modify a feature.
2/ You're raising a real issue for beginners and even for others for use
cases where Timer needs to be controlled more precisely for a
TransactionController or any controller.
3/ With your feature you make it more "user friendly" when timer is at same
level of a Sampler, it will execute after it. But it doesn't answer the
case where you have 1 Transaction controller that has N HttpSampler as it
would execute before each HttpSampler.
The Macro feature would answer this, You raise the size of Test Plan it is
an argument but not sure for complex cases that it impact is bigger than
regular timers configuration.
Anyway, thanks a lot Andrey for your work on the project since you're a
commiter and of course for your work on plugins !
And thanks to all feedback.
Regards
Philippe
On Thu, Apr 16, 2015 at 12:46 PM, Shmuel Krakower <sh...@gmail.com>
wrote:
> Well, that's just my own feedback / opinion.
> It doesn't reflect others.
>
> If the new implementation feels right, I'll adopt it, I just cannot see the
> benefit of that, yet.
> Neither I don't see the issue with having "Think Time" elements between
> actions, such as: http://pasteboard.co/2BDxVS03.png
> What do you mean by "...which makes test plan too
> heavy." ?
>
> Shmuel Krakower.
> www.Beatsoo.org - re-use your jmeter scripts for application performance
> monitoring from worldwide locations for free.
>
> On Wed, Apr 15, 2015 at 4:19 PM, Andrey Pokhilko <ap...@ya.ru> wrote:
>
> > But the sampler approach (test action is also a sampler) requires to
> > have a pause element after each sampler, which makes test plan too
> > heavy. Timers have scoping, this allows lean test-plan building. That's
> > why I want to have post-sample timers.
> >
> > Andrey Pokhilko
> >
> > On 04/15/2015 03:12 PM, Shmuel Krakower wrote:
> > > Hi,
> > > I do exactly as ubikloadpack mentioned which makes things a lot easier
> to
> > > look at.
> > > I don't see much value with pre_sleep and post_sleep.
> > > It would have been nice to have a "sleep sampler", which will reduce
> the
> > > need to create TestAction with Timer in it, as done today.
> > >
> > > Best,
> > >
> > >
> > >
> > > Shmuel Krakower.
> > > www.Beatsoo.org - re-use your jmeter scripts for application
> performance
> > > monitoring from worldwide locations for free.
> > >
> > > On Wed, Apr 15, 2015 at 12:37 PM, UBIK LOAD PACK Support <
> > > support@ubikloadpack.com> wrote:
> > >
> > >> Hi,
> > >> Very good idea !
> > >> We always use the following strategy to have this feature:
> > >>
> > >> - Use TestAction with 0 sleep and nest in it the Timer. This way
> > timer
> > >> pauses where it is located for the expected time and not
> > SampleResult is
> > >> generated.
> > >>
> > >> So you idea would help as it is a bit harder to maintain.
> > >> One note although, how would you handle scoping ?
> > >> Would it stay as is ? If yes, won't code be difficult and clumsy ?
> > >>
> > >> Regards
> > >> @ubikloadpack
> > >>
> > >> On Wed, Apr 15, 2015 at 11:32 AM, Andrey Pokhilko <ap...@ya.ru> wrote:
> > >>
> > >>> Hi,
> > >>>
> > >>> When I try to introduce JMeter to new people, I frequently see them
> > >>> confused with our way to set "think times" before request. Especially
> > >>> those who used to use some other testing tools, where think-time is
> > >>> _after_ request.
> > >>>
> > >>> I personally think that think-time should be made after request,
> > because
> > >>> its duration depends on the results of the request. If you have got
> > long
> > >>> text as a result of your request, you supposed to spend some time
> > >>> reading it. If you have short error message, you supposed to do your
> > >>> next request much faster. The _delay_ time before request still makes
> > >>> sense, because it allows manipulating throughput and synchronize
> > >> requests.
> > >>> I would like to contribute to JMeter following changes:
> > >>>
> > >>> 1. Add a property for Timers, marking them as "pre-sampler" or
> > >>> "post-sampler" timers
> > >>> 2. Modify thread execution flow to call pre-timers and post-timers
> > >>> accordingly
> > >>> 3. Modify timers UIs where it is reasonable, adding radio button to
> > >>> change timer mode
> > >>>
> > >>>
> > >>> Any thoughts/objections on this?
> > >>>
> > >>> --
> > >>> Andrey Pokhilko
> > >>>
> > >>>
> > >>
> > >> --
> > >>
> > >> Regards
> > >> Ubik Load Pack <http://ubikloadpack.com> Team
> > >> Follow us on Twitter <http://twitter.com/ubikloadpack>
> > >>
> > >>
> > >> Cordialement
> > >> L'équipe Ubik Load Pack <http://ubikloadpack.com>
> > >> Suivez-nous sur Twitter <http://twitter.com/ubikloadpack>
> > >>
> >
> >
>
--
Cordialement.
Philippe Mouawad.
Re: Post-Sampler Timers
Posted by Shmuel Krakower <sh...@gmail.com>.
Well, that's just my own feedback / opinion.
It doesn't reflect others.
If the new implementation feels right, I'll adopt it, I just cannot see the
benefit of that, yet.
Neither I don't see the issue with having "Think Time" elements between
actions, such as: http://pasteboard.co/2BDxVS03.png
What do you mean by "...which makes test plan too
heavy." ?
Shmuel Krakower.
www.Beatsoo.org - re-use your jmeter scripts for application performance
monitoring from worldwide locations for free.
On Wed, Apr 15, 2015 at 4:19 PM, Andrey Pokhilko <ap...@ya.ru> wrote:
> But the sampler approach (test action is also a sampler) requires to
> have a pause element after each sampler, which makes test plan too
> heavy. Timers have scoping, this allows lean test-plan building. That's
> why I want to have post-sample timers.
>
> Andrey Pokhilko
>
> On 04/15/2015 03:12 PM, Shmuel Krakower wrote:
> > Hi,
> > I do exactly as ubikloadpack mentioned which makes things a lot easier to
> > look at.
> > I don't see much value with pre_sleep and post_sleep.
> > It would have been nice to have a "sleep sampler", which will reduce the
> > need to create TestAction with Timer in it, as done today.
> >
> > Best,
> >
> >
> >
> > Shmuel Krakower.
> > www.Beatsoo.org - re-use your jmeter scripts for application performance
> > monitoring from worldwide locations for free.
> >
> > On Wed, Apr 15, 2015 at 12:37 PM, UBIK LOAD PACK Support <
> > support@ubikloadpack.com> wrote:
> >
> >> Hi,
> >> Very good idea !
> >> We always use the following strategy to have this feature:
> >>
> >> - Use TestAction with 0 sleep and nest in it the Timer. This way
> timer
> >> pauses where it is located for the expected time and not
> SampleResult is
> >> generated.
> >>
> >> So you idea would help as it is a bit harder to maintain.
> >> One note although, how would you handle scoping ?
> >> Would it stay as is ? If yes, won't code be difficult and clumsy ?
> >>
> >> Regards
> >> @ubikloadpack
> >>
> >> On Wed, Apr 15, 2015 at 11:32 AM, Andrey Pokhilko <ap...@ya.ru> wrote:
> >>
> >>> Hi,
> >>>
> >>> When I try to introduce JMeter to new people, I frequently see them
> >>> confused with our way to set "think times" before request. Especially
> >>> those who used to use some other testing tools, where think-time is
> >>> _after_ request.
> >>>
> >>> I personally think that think-time should be made after request,
> because
> >>> its duration depends on the results of the request. If you have got
> long
> >>> text as a result of your request, you supposed to spend some time
> >>> reading it. If you have short error message, you supposed to do your
> >>> next request much faster. The _delay_ time before request still makes
> >>> sense, because it allows manipulating throughput and synchronize
> >> requests.
> >>> I would like to contribute to JMeter following changes:
> >>>
> >>> 1. Add a property for Timers, marking them as "pre-sampler" or
> >>> "post-sampler" timers
> >>> 2. Modify thread execution flow to call pre-timers and post-timers
> >>> accordingly
> >>> 3. Modify timers UIs where it is reasonable, adding radio button to
> >>> change timer mode
> >>>
> >>>
> >>> Any thoughts/objections on this?
> >>>
> >>> --
> >>> Andrey Pokhilko
> >>>
> >>>
> >>
> >> --
> >>
> >> Regards
> >> Ubik Load Pack <http://ubikloadpack.com> Team
> >> Follow us on Twitter <http://twitter.com/ubikloadpack>
> >>
> >>
> >> Cordialement
> >> L'équipe Ubik Load Pack <http://ubikloadpack.com>
> >> Suivez-nous sur Twitter <http://twitter.com/ubikloadpack>
> >>
>
>
Re: Post-Sampler Timers
Posted by Andrey Pokhilko <ap...@ya.ru>.
But the sampler approach (test action is also a sampler) requires to
have a pause element after each sampler, which makes test plan too
heavy. Timers have scoping, this allows lean test-plan building. That's
why I want to have post-sample timers.
Andrey Pokhilko
On 04/15/2015 03:12 PM, Shmuel Krakower wrote:
> Hi,
> I do exactly as ubikloadpack mentioned which makes things a lot easier to
> look at.
> I don't see much value with pre_sleep and post_sleep.
> It would have been nice to have a "sleep sampler", which will reduce the
> need to create TestAction with Timer in it, as done today.
>
> Best,
>
>
>
> Shmuel Krakower.
> www.Beatsoo.org - re-use your jmeter scripts for application performance
> monitoring from worldwide locations for free.
>
> On Wed, Apr 15, 2015 at 12:37 PM, UBIK LOAD PACK Support <
> support@ubikloadpack.com> wrote:
>
>> Hi,
>> Very good idea !
>> We always use the following strategy to have this feature:
>>
>> - Use TestAction with 0 sleep and nest in it the Timer. This way timer
>> pauses where it is located for the expected time and not SampleResult is
>> generated.
>>
>> So you idea would help as it is a bit harder to maintain.
>> One note although, how would you handle scoping ?
>> Would it stay as is ? If yes, won't code be difficult and clumsy ?
>>
>> Regards
>> @ubikloadpack
>>
>> On Wed, Apr 15, 2015 at 11:32 AM, Andrey Pokhilko <ap...@ya.ru> wrote:
>>
>>> Hi,
>>>
>>> When I try to introduce JMeter to new people, I frequently see them
>>> confused with our way to set "think times" before request. Especially
>>> those who used to use some other testing tools, where think-time is
>>> _after_ request.
>>>
>>> I personally think that think-time should be made after request, because
>>> its duration depends on the results of the request. If you have got long
>>> text as a result of your request, you supposed to spend some time
>>> reading it. If you have short error message, you supposed to do your
>>> next request much faster. The _delay_ time before request still makes
>>> sense, because it allows manipulating throughput and synchronize
>> requests.
>>> I would like to contribute to JMeter following changes:
>>>
>>> 1. Add a property for Timers, marking them as "pre-sampler" or
>>> "post-sampler" timers
>>> 2. Modify thread execution flow to call pre-timers and post-timers
>>> accordingly
>>> 3. Modify timers UIs where it is reasonable, adding radio button to
>>> change timer mode
>>>
>>>
>>> Any thoughts/objections on this?
>>>
>>> --
>>> Andrey Pokhilko
>>>
>>>
>>
>> --
>>
>> Regards
>> Ubik Load Pack <http://ubikloadpack.com> Team
>> Follow us on Twitter <http://twitter.com/ubikloadpack>
>>
>>
>> Cordialement
>> L'équipe Ubik Load Pack <http://ubikloadpack.com>
>> Suivez-nous sur Twitter <http://twitter.com/ubikloadpack>
>>
Re: Post-Sampler Timers
Posted by Shmuel Krakower <sh...@gmail.com>.
Hi,
I do exactly as ubikloadpack mentioned which makes things a lot easier to
look at.
I don't see much value with pre_sleep and post_sleep.
It would have been nice to have a "sleep sampler", which will reduce the
need to create TestAction with Timer in it, as done today.
Best,
Shmuel Krakower.
www.Beatsoo.org - re-use your jmeter scripts for application performance
monitoring from worldwide locations for free.
On Wed, Apr 15, 2015 at 12:37 PM, UBIK LOAD PACK Support <
support@ubikloadpack.com> wrote:
> Hi,
> Very good idea !
> We always use the following strategy to have this feature:
>
> - Use TestAction with 0 sleep and nest in it the Timer. This way timer
> pauses where it is located for the expected time and not SampleResult is
> generated.
>
> So you idea would help as it is a bit harder to maintain.
> One note although, how would you handle scoping ?
> Would it stay as is ? If yes, won't code be difficult and clumsy ?
>
> Regards
> @ubikloadpack
>
> On Wed, Apr 15, 2015 at 11:32 AM, Andrey Pokhilko <ap...@ya.ru> wrote:
>
> > Hi,
> >
> > When I try to introduce JMeter to new people, I frequently see them
> > confused with our way to set "think times" before request. Especially
> > those who used to use some other testing tools, where think-time is
> > _after_ request.
> >
> > I personally think that think-time should be made after request, because
> > its duration depends on the results of the request. If you have got long
> > text as a result of your request, you supposed to spend some time
> > reading it. If you have short error message, you supposed to do your
> > next request much faster. The _delay_ time before request still makes
> > sense, because it allows manipulating throughput and synchronize
> requests.
> >
> > I would like to contribute to JMeter following changes:
> >
> > 1. Add a property for Timers, marking them as "pre-sampler" or
> > "post-sampler" timers
> > 2. Modify thread execution flow to call pre-timers and post-timers
> > accordingly
> > 3. Modify timers UIs where it is reasonable, adding radio button to
> > change timer mode
> >
> >
> > Any thoughts/objections on this?
> >
> > --
> > Andrey Pokhilko
> >
> >
>
>
> --
>
> Regards
> Ubik Load Pack <http://ubikloadpack.com> Team
> Follow us on Twitter <http://twitter.com/ubikloadpack>
>
>
> Cordialement
> L'équipe Ubik Load Pack <http://ubikloadpack.com>
> Suivez-nous sur Twitter <http://twitter.com/ubikloadpack>
>
Re: Post-Sampler Timers
Posted by Andrey Pokhilko <ap...@ya.ru>.
The scoping will stay the same.
The implementation will be pretty straightforward and I don't see any
complications, just couple of "if" statements.
Andrey Pokhilko
On 04/15/2015 12:37 PM, UBIK LOAD PACK Support wrote:
> Hi,
> Very good idea !
> We always use the following strategy to have this feature:
>
> - Use TestAction with 0 sleep and nest in it the Timer. This way timer
> pauses where it is located for the expected time and not SampleResult is
> generated.
>
> So you idea would help as it is a bit harder to maintain.
> One note although, how would you handle scoping ?
> Would it stay as is ? If yes, won't code be difficult and clumsy ?
>
> Regards
> @ubikloadpack
>
> On Wed, Apr 15, 2015 at 11:32 AM, Andrey Pokhilko <ap...@ya.ru> wrote:
>
>> Hi,
>>
>> When I try to introduce JMeter to new people, I frequently see them
>> confused with our way to set "think times" before request. Especially
>> those who used to use some other testing tools, where think-time is
>> _after_ request.
>>
>> I personally think that think-time should be made after request, because
>> its duration depends on the results of the request. If you have got long
>> text as a result of your request, you supposed to spend some time
>> reading it. If you have short error message, you supposed to do your
>> next request much faster. The _delay_ time before request still makes
>> sense, because it allows manipulating throughput and synchronize requests.
>>
>> I would like to contribute to JMeter following changes:
>>
>> 1. Add a property for Timers, marking them as "pre-sampler" or
>> "post-sampler" timers
>> 2. Modify thread execution flow to call pre-timers and post-timers
>> accordingly
>> 3. Modify timers UIs where it is reasonable, adding radio button to
>> change timer mode
>>
>>
>> Any thoughts/objections on this?
>>
>> --
>> Andrey Pokhilko
>>
>>
>
Re: Post-Sampler Timers
Posted by UBIK LOAD PACK Support <su...@ubikloadpack.com>.
Hi,
Very good idea !
We always use the following strategy to have this feature:
- Use TestAction with 0 sleep and nest in it the Timer. This way timer
pauses where it is located for the expected time and not SampleResult is
generated.
So you idea would help as it is a bit harder to maintain.
One note although, how would you handle scoping ?
Would it stay as is ? If yes, won't code be difficult and clumsy ?
Regards
@ubikloadpack
On Wed, Apr 15, 2015 at 11:32 AM, Andrey Pokhilko <ap...@ya.ru> wrote:
> Hi,
>
> When I try to introduce JMeter to new people, I frequently see them
> confused with our way to set "think times" before request. Especially
> those who used to use some other testing tools, where think-time is
> _after_ request.
>
> I personally think that think-time should be made after request, because
> its duration depends on the results of the request. If you have got long
> text as a result of your request, you supposed to spend some time
> reading it. If you have short error message, you supposed to do your
> next request much faster. The _delay_ time before request still makes
> sense, because it allows manipulating throughput and synchronize requests.
>
> I would like to contribute to JMeter following changes:
>
> 1. Add a property for Timers, marking them as "pre-sampler" or
> "post-sampler" timers
> 2. Modify thread execution flow to call pre-timers and post-timers
> accordingly
> 3. Modify timers UIs where it is reasonable, adding radio button to
> change timer mode
>
>
> Any thoughts/objections on this?
>
> --
> Andrey Pokhilko
>
>
--
Regards
Ubik Load Pack <http://ubikloadpack.com> Team
Follow us on Twitter <http://twitter.com/ubikloadpack>
Cordialement
L'équipe Ubik Load Pack <http://ubikloadpack.com>
Suivez-nous sur Twitter <http://twitter.com/ubikloadpack>