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 <ph...@gmail.com> on 2017/02/26 09:52:14 UTC
Mailer Visualizer
Hello,
This element might be more useful if we can make some enhancements to it:
- First rename it as its name is far from clear. Something like Mail
Alerter
- Make it send notifications on richer conditions:
- Percentile 90 of response time (Excluding Transaction Controller)
reaching a limit
- Errors percentage reaching a limit
- Burst in error percentage
- ...
- Possibly be able to express a rule in Groovy
Currently it seems to me far from useful as is.
Regards
Philippe
Re: Mailer Visualizer
Posted by sebb <se...@gmail.com>.
On 26 February 2017 at 12:51, Philippe Mouawad
<ph...@gmail.com> wrote:
> On Sun, Feb 26, 2017 at 1:44 PM, sebb <se...@gmail.com> wrote:
>
>> On 26 February 2017 at 12:33, Philippe Mouawad
>> <ph...@gmail.com> wrote:
>> > On Sun, Feb 26, 2017 at 1:15 PM, sebb <se...@gmail.com> wrote:
>> >
>> >> On 26 February 2017 at 09:52, Philippe Mouawad
>> >> <ph...@gmail.com> wrote:
>> >> > Hello,
>> >> > This element might be more useful if we can make some enhancements to
>> it:
>> >> >
>> >> > - First rename it as its name is far from clear. Something like
>> Mail
>> >> > Alerter
>> >> > - Make it send notifications on richer conditions:
>> >> > - Percentile 90 of response time (Excluding Transaction
>> Controller)
>> >> > reaching a limit
>> >> > - Errors percentage reaching a limit
>> >> > - Burst in error percentage
>> >> > - ...
>> >> > - Possibly be able to express a rule in Groovy
>> >> >
>> >> > Currently it seems to me far from useful as is.
>> >>
>> >> I suggest you ask on the User list how it is being used.
>> >>
>> >> Also, I would be wary of adding too much functionality into the
>> listener.
>> >> It should just be a means to send the email, the same as other
>> >> Listeners are a means to displaying results or recording them in a
>> >> file or database.
>> >> Error checks should be done by Assertions.
>> >>
>> > In my understanding Assertion applies on every sample. Can it apply to a
>> > history of samplers ?
>>
>> Listeners also apply to each sample, yet the Mailer Visualizer is able
>> to look at history, so Assertions can use the same technique.
>>
>> > Maybe a simple addition would be to allow Mailer Visualizer to send a
>> mail
>> > based on variable or property value (true/ false).
>> > This would make it very flexible. We could this way combine it with
>> > GenerateSummary Result or a dedicated "Alert" listener which could set
>> this
>> > variable or property.
>>
>> That would be better, but the "Alert" test element should be an
>> Assertion not a Listener.
>>
> Its usage would be confusing .
> Assertion are here to mark a sampler in error, so you could randomly get
> any sampler marked in error whenever the alert conditions are met.
Depends on how the Alert assertion records the outcome.
It would not make sense to change the sample status.
> A listener is more "global" as such it seems to me a better place for that.
I don't see a Listener that way; it is a test element that processes
samples, just as an Assertion processes samples.
It is only global if it is in global scope.
An assertion analyses sampler responses.
A listener records or displays them.
Therefore the Alert element should be an Assertion.
>
>>
>> This would allow it to be more general; e.g. one could stop a test if
>> the error percentage was too high.
>>
>> >
>> >> As far as possible, each test element should have a single role.
>> >> This reduces duplication and allows easier testing.
>> >>
>> > I agree
>> >
>> >>
>> >> >
>> >> > Regards
>> >> >
>> >> > Philippe
>> >>
>> >
>> >
>> >
>> > --
>> > Cordialement.
>> > Philippe Mouawad.
>>
>
>
>
> --
> Cordialement.
> Philippe Mouawad.
Re: Mailer Visualizer
Posted by Philippe Mouawad <ph...@gmail.com>.
On Sun, Feb 26, 2017 at 1:44 PM, sebb <se...@gmail.com> wrote:
> On 26 February 2017 at 12:33, Philippe Mouawad
> <ph...@gmail.com> wrote:
> > On Sun, Feb 26, 2017 at 1:15 PM, sebb <se...@gmail.com> wrote:
> >
> >> On 26 February 2017 at 09:52, Philippe Mouawad
> >> <ph...@gmail.com> wrote:
> >> > Hello,
> >> > This element might be more useful if we can make some enhancements to
> it:
> >> >
> >> > - First rename it as its name is far from clear. Something like
> Mail
> >> > Alerter
> >> > - Make it send notifications on richer conditions:
> >> > - Percentile 90 of response time (Excluding Transaction
> Controller)
> >> > reaching a limit
> >> > - Errors percentage reaching a limit
> >> > - Burst in error percentage
> >> > - ...
> >> > - Possibly be able to express a rule in Groovy
> >> >
> >> > Currently it seems to me far from useful as is.
> >>
> >> I suggest you ask on the User list how it is being used.
> >>
> >> Also, I would be wary of adding too much functionality into the
> listener.
> >> It should just be a means to send the email, the same as other
> >> Listeners are a means to displaying results or recording them in a
> >> file or database.
> >> Error checks should be done by Assertions.
> >>
> > In my understanding Assertion applies on every sample. Can it apply to a
> > history of samplers ?
>
> Listeners also apply to each sample, yet the Mailer Visualizer is able
> to look at history, so Assertions can use the same technique.
>
> > Maybe a simple addition would be to allow Mailer Visualizer to send a
> mail
> > based on variable or property value (true/ false).
> > This would make it very flexible. We could this way combine it with
> > GenerateSummary Result or a dedicated "Alert" listener which could set
> this
> > variable or property.
>
> That would be better, but the "Alert" test element should be an
> Assertion not a Listener.
>
Its usage would be confusing .
Assertion are here to mark a sampler in error, so you could randomly get
any sampler marked in error whenever the alert conditions are met.
A listener is more "global" as such it seems to me a better place for that.
>
> This would allow it to be more general; e.g. one could stop a test if
> the error percentage was too high.
>
> >
> >> As far as possible, each test element should have a single role.
> >> This reduces duplication and allows easier testing.
> >>
> > I agree
> >
> >>
> >> >
> >> > Regards
> >> >
> >> > Philippe
> >>
> >
> >
> >
> > --
> > Cordialement.
> > Philippe Mouawad.
>
--
Cordialement.
Philippe Mouawad.
Re: Mailer Visualizer
Posted by sebb <se...@gmail.com>.
On 26 February 2017 at 12:33, Philippe Mouawad
<ph...@gmail.com> wrote:
> On Sun, Feb 26, 2017 at 1:15 PM, sebb <se...@gmail.com> wrote:
>
>> On 26 February 2017 at 09:52, Philippe Mouawad
>> <ph...@gmail.com> wrote:
>> > Hello,
>> > This element might be more useful if we can make some enhancements to it:
>> >
>> > - First rename it as its name is far from clear. Something like Mail
>> > Alerter
>> > - Make it send notifications on richer conditions:
>> > - Percentile 90 of response time (Excluding Transaction Controller)
>> > reaching a limit
>> > - Errors percentage reaching a limit
>> > - Burst in error percentage
>> > - ...
>> > - Possibly be able to express a rule in Groovy
>> >
>> > Currently it seems to me far from useful as is.
>>
>> I suggest you ask on the User list how it is being used.
>>
>> Also, I would be wary of adding too much functionality into the listener.
>> It should just be a means to send the email, the same as other
>> Listeners are a means to displaying results or recording them in a
>> file or database.
>> Error checks should be done by Assertions.
>>
> In my understanding Assertion applies on every sample. Can it apply to a
> history of samplers ?
Listeners also apply to each sample, yet the Mailer Visualizer is able
to look at history, so Assertions can use the same technique.
> Maybe a simple addition would be to allow Mailer Visualizer to send a mail
> based on variable or property value (true/ false).
> This would make it very flexible. We could this way combine it with
> GenerateSummary Result or a dedicated "Alert" listener which could set this
> variable or property.
That would be better, but the "Alert" test element should be an
Assertion not a Listener.
This would allow it to be more general; e.g. one could stop a test if
the error percentage was too high.
>
>> As far as possible, each test element should have a single role.
>> This reduces duplication and allows easier testing.
>>
> I agree
>
>>
>> >
>> > Regards
>> >
>> > Philippe
>>
>
>
>
> --
> Cordialement.
> Philippe Mouawad.
Re: Mailer Visualizer
Posted by Philippe Mouawad <ph...@gmail.com>.
On Sun, Feb 26, 2017 at 1:15 PM, sebb <se...@gmail.com> wrote:
> On 26 February 2017 at 09:52, Philippe Mouawad
> <ph...@gmail.com> wrote:
> > Hello,
> > This element might be more useful if we can make some enhancements to it:
> >
> > - First rename it as its name is far from clear. Something like Mail
> > Alerter
> > - Make it send notifications on richer conditions:
> > - Percentile 90 of response time (Excluding Transaction Controller)
> > reaching a limit
> > - Errors percentage reaching a limit
> > - Burst in error percentage
> > - ...
> > - Possibly be able to express a rule in Groovy
> >
> > Currently it seems to me far from useful as is.
>
> I suggest you ask on the User list how it is being used.
>
> Also, I would be wary of adding too much functionality into the listener.
> It should just be a means to send the email, the same as other
> Listeners are a means to displaying results or recording them in a
> file or database.
> Error checks should be done by Assertions.
>
In my understanding Assertion applies on every sample. Can it apply to a
history of samplers ?
Maybe a simple addition would be to allow Mailer Visualizer to send a mail
based on variable or property value (true/ false).
This would make it very flexible. We could this way combine it with
GenerateSummary Result or a dedicated "Alert" listener which could set this
variable or property.
> As far as possible, each test element should have a single role.
> This reduces duplication and allows easier testing.
>
I agree
>
> >
> > Regards
> >
> > Philippe
>
--
Cordialement.
Philippe Mouawad.
Re: Mailer Visualizer
Posted by sebb <se...@gmail.com>.
On 26 February 2017 at 09:52, Philippe Mouawad
<ph...@gmail.com> wrote:
> Hello,
> This element might be more useful if we can make some enhancements to it:
>
> - First rename it as its name is far from clear. Something like Mail
> Alerter
> - Make it send notifications on richer conditions:
> - Percentile 90 of response time (Excluding Transaction Controller)
> reaching a limit
> - Errors percentage reaching a limit
> - Burst in error percentage
> - ...
> - Possibly be able to express a rule in Groovy
>
> Currently it seems to me far from useful as is.
I suggest you ask on the User list how it is being used.
Also, I would be wary of adding too much functionality into the listener.
It should just be a means to send the email, the same as other
Listeners are a means to displaying results or recording them in a
file or database.
Error checks should be done by Assertions.
As far as possible, each test element should have a single role.
This reduces duplication and allows easier testing.
>
> Regards
>
> Philippe