Mailing-List: contact dev-help@jmeter.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jmeter.apache.org
Received-SPF: pass (athena.apache.org: domain of philippe.mouawad@gmail.com
 designates 209.85.213.172 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAOGo0VY=oWZSrXsMfDFQ_pw4oYACrORSxzQgAHBWX59PrGWpZQ@mail.gmail.com>
References: 
 <CAH9fUpYxB7vDb3LLS0ncQ7aGUqVPkrvuJif8Zj20_eLkjMiLOQ@mail.gmail.com>
	<CAH9fUpYX_L8aiu83oo9R1k45n=-7-_wCvVaMAXCwTqL=eh=Zuw@mail.gmail.com>
	<CAOGo0VY=oWZSrXsMfDFQ_pw4oYACrORSxzQgAHBWX59PrGWpZQ@mail.gmail.com>
Date: Wed, 1 Jan 2014 23:55:50 +0100
Message-ID: 
 <CAH9fUpbt-_x1fFcYCTn9fVEqFL68E_N9YLkkhYs4RnpiRSx+Og@mail.gmail.com>
Subject: Re: About Backend & Backend Listener Implementation
From: Philippe Mouawad <philippe.mouawad@gmail.com>
To: "dev@jmeter.apache.org" <dev@jmeter.apache.org>
Content-Type: multipart/alternative; boundary=089e0122f6ae11c05104eef09426

--089e0122f6ae11c05104eef09426
Content-Type: text/plain; charset=ISO-8859-1

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.

--089e0122f6ae11c05104eef09426--