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 2014/01/01 22:35:45 UTC
About Backend & Backend Listener Implementation
Hello,
To be sure we agree I propose the following way to implement it:
- BackendListener will be similar to current Graphite Listener attached in
Patch for https://issues.apache.org/bugzilla/show_bug.cgi?id=55932
- Any Graphite specificity will be moved out
So:
- Current metrics will be named the same
- Percentiles will be computed in the same way based on commons-math3 (so
1.2 Mb increase)
- Filtering will remain
- Listener will search for Backend implementations in BeanInfo class to
propose a list of backends to user that it will later use
--
Regards.
Philippe M
Re: About Backend & Backend Listener Implementation
Posted by Philippe Mouawad <ph...@gmail.com>.
On Wednesday, January 1, 2014, sebb wrote:
> I don't see why the calculations should be done by JMeter.
To make it simple. As a user these are the minimums I want and would really
appreciate not to have to compute them by myself.
Check patch to see how it computes, it computes a synthesis accross time
and does not send the whole sampleresults.
> Not everyone will necessarily need all the ones proposed - and some
> may want additional calculations done on the data.
In this case, it seems to me it is another requirement more related to
storing full test results.
The way you want it would become more complex to use with Graphite for
example.
>
> I would prefer to see just an API for storing just the raw data.
The Api I was thinking about would send list of SamplerMetric
> This should ideally be extendable to cater for more raw data items.
we could make this
> Not sure I can think of any immediately, but as I recall latency was
> not originally measured.
>
> Anything further should be done in the implementation.
>
> Perhaps the implementations should consist of a GUI Config element (or
> similar) which is used to provide the settings, plus a separate class
> to implement the data sink.
>
> The Listener would then display a list of implementations for the user
> to choose.
>
> Or perhaps the interface could be more like the Java Sampler, where
> the implementation class contains details of the settings that are
> then diplayed on the GUI. That should make it simpler to implement the
> add-on
Ok
> On 1 January 2014 21:39, Philippe Mouawad <philippe.mouawad@gmail.com<javascript:;>>
> wrote:
> > One last point:
> > - properties required for one implementation of backend will use
> > jmeter.properties/user.properties, for example (jdbc url, login,password,
> > graphite host, port, database)
> >
> >
> > On Wed, Jan 1, 2014 at 10:35 PM, Philippe Mouawad <
> > philippe.mouawad@gmail.com <javascript:;>> wrote:
> >
> >> Hello,
> >> To be sure we agree I propose the following way to implement it:
> >> - BackendListener will be similar to current Graphite Listener attached
> in
> >> Patch for https://issues.apache.org/bugzilla/show_bug.cgi?id=55932
> >> - Any Graphite specificity will be moved out
> >>
> >> So:
> >> - Current metrics will be named the same
> >> - Percentiles will be computed in the same way based on commons-math3
> (so
> >> 1.2 Mb increase)
> >> - Filtering will remain
> >> - Listener will search for Backend implementations in BeanInfo class to
> >> propose a list of backends to user that it will later use
> >>
> >> --
> >> Regards.
> >> Philippe M
> >>
> >
> >
> >
> > --
> > Cordialement.
> > Philippe Mouawad.
>
--
Cordialement.
Philippe Mouawad.
Re: About Backend & Backend Listener Implementation
Posted by sebb <se...@gmail.com>.
I don't see why the calculations should be done by JMeter.
Not everyone will necessarily need all the ones proposed - and some
may want additional calculations done on the data.
I would prefer to see just an API for storing just the raw data.
This should ideally be extendable to cater for more raw data items.
Not sure I can think of any immediately, but as I recall latency was
not originally measured.
Anything further should be done in the implementation.
Perhaps the implementations should consist of a GUI Config element (or
similar) which is used to provide the settings, plus a separate class
to implement the data sink.
The Listener would then display a list of implementations for the user
to choose.
Or perhaps the interface could be more like the Java Sampler, where
the implementation class contains details of the settings that are
then diplayed on the GUI. That should make it simpler to implement the
add-on
On 1 January 2014 21:39, Philippe Mouawad <ph...@gmail.com> wrote:
> One last point:
> - properties required for one implementation of backend will use
> jmeter.properties/user.properties, for example (jdbc url, login,password,
> graphite host, port, database)
>
>
> On Wed, Jan 1, 2014 at 10:35 PM, Philippe Mouawad <
> philippe.mouawad@gmail.com> wrote:
>
>> Hello,
>> To be sure we agree I propose the following way to implement it:
>> - BackendListener will be similar to current Graphite Listener attached in
>> Patch for https://issues.apache.org/bugzilla/show_bug.cgi?id=55932
>> - Any Graphite specificity will be moved out
>>
>> So:
>> - Current metrics will be named the same
>> - Percentiles will be computed in the same way based on commons-math3 (so
>> 1.2 Mb increase)
>> - Filtering will remain
>> - Listener will search for Backend implementations in BeanInfo class to
>> propose a list of backends to user that it will later use
>>
>> --
>> Regards.
>> Philippe M
>>
>
>
>
> --
> Cordialement.
> Philippe Mouawad.
Re: About Backend & Backend Listener Implementation
Posted by Philippe Mouawad <ph...@gmail.com>.
One last point:
- properties required for one implementation of backend will use
jmeter.properties/user.properties, for example (jdbc url, login,password,
graphite host, port, database)
On Wed, Jan 1, 2014 at 10:35 PM, Philippe Mouawad <
philippe.mouawad@gmail.com> wrote:
> Hello,
> To be sure we agree I propose the following way to implement it:
> - BackendListener will be similar to current Graphite Listener attached in
> Patch for https://issues.apache.org/bugzilla/show_bug.cgi?id=55932
> - Any Graphite specificity will be moved out
>
> So:
> - Current metrics will be named the same
> - Percentiles will be computed in the same way based on commons-math3 (so
> 1.2 Mb increase)
> - Filtering will remain
> - Listener will search for Backend implementations in BeanInfo class to
> propose a list of backends to user that it will later use
>
> --
> Regards.
> Philippe M
>
--
Cordialement.
Philippe Mouawad.