You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@jmeter.apache.org by bu...@apache.org on 2013/12/26 00:14:14 UTC
[Bug 55932] New: Create a Graphite Listener
https://issues.apache.org/bugzilla/show_bug.cgi?id=55932
Bug ID: 55932
Summary: Create a Graphite Listener
Product: JMeter
Version: 2.10
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P2
Component: Main
Assignee: issues@jmeter.apache.org
Reporter: p.mouawad@ubik-ingenierie.com
Created attachment 31154
--> https://issues.apache.org/bugzilla/attachment.cgi?id=31154&action=edit
Graphite Dashboard for cumulated data
Graphite is an interesting way to have graphs rendered live and on demand:
http://graphite.readthedocs.org/en/latest/overview.html
With this Bugzilla I propose to create the following:
A new listener that will send the following metrics
1) Per second:
- min response time
- max response time
- percentile 90 for response time rolling over last 100 values
- percentile 95 for response time rolling over last 100 values
- successful req
- failed req
- total req
2) Listener will also send the following metrics which are not based on a
variation per second:
- ActiveThreads
- Stopped Threads
- Started Threads
I suggest to use commons-math for percentile computations (which by the way
could be useful in other parts of JMeter).
I also suggest using Pickle protocol as it seems to be the most efficient as
per Graphite docs:
http://graphite.readthedocs.org/en/latest/feeding-carbon.html
Reviewing existing libraries, I didn't find a reference for Graphite client in
Java but my final implementation is partly based on this:
-
https://github.com/BrightcoveOS/metrics-graphite-pickle/blob/master/src/main/java/com/brightcove/metrics/reporting/GraphitePickleReporter.java
Only using the pickle protocol part and adding:
- Socket Pooling based on commons-pool2 to avoid overcreating sockets
Additional dependencies:
- Apache commons-pool2
- Apache commons-math3
See attached example of a generated Dashboard
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 55932] Create a Graphite Listener
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55932
--- Comment #2 from Milamber <mi...@apache.org> ---
I've tested the listener with a Graphite server on a virtual machine on my
machine.
Seems works fine, but I don't find the response time graph in elements list
(see screenshot).
I've following this tutorial to install the graphite server (on debian 7)
https://www.digitalocean.com/community/articles/installing-and-configuring-graphite-and-statsd-on-an-ubuntu-12-04-vps
Perhaps I missing something?
Note, the ant tests task don't work. I put the trace in another comment.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 55932] Create a Async BackendListener to allow easy plug of new
listener (Graphite, JDBC, Console,...)
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55932
Philippe Mouawad <p....@ubik-ingenierie.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Depends on| |57321
--
You are receiving this mail because:
You are the assignee for the bug.
Re: [Bug 55932] Create a Graphite Listener
Posted by sebb <se...@gmail.com>.
On 3 January 2014 14:45, Philippe Mouawad <ph...@gmail.com> wrote:
> On Fri, Jan 3, 2014 at 3:33 PM, sebb <se...@gmail.com> wrote:
>
>> On 3 January 2014 13:47, Philippe Mouawad <ph...@gmail.com>
>> wrote:
>> > Hello Sebb,
>> > As requested although I don't see why it cannot be in bugzilla,if it were
>> > the history of discussion could be found more easily.
>>
>> Because discussion may take a while and Bugzilla is not good for that.
>> We can add links to the mail thread with any followup, once decisions are
>> made.
>>
>> > Regards
>> > Philippe
>> > On Fri, Jan 3, 2014 at 1:57 PM, <bu...@apache.org> wrote:
>> >
>> >> https://issues.apache.org/bugzilla/show_bug.cgi?id=55932
>> >>
>> >> --- Comment #6 from Sebb <se...@apache.org> ---
>> >> I have been having a look at the implementation.
>> >>
>> >> I don't really see that it needs Commons Math; we aleady have
>> >> StatCalculator
>> >> which handles percentiles and more.
>> >>
>> > Ok I can change this.
>> >
>> >>
>> >> Likewise, does it really need Commons Pool?
>> >> It seems wrong to have to have 2 separate pools of SocketOutputStream
>> >> instances.
>> >>
>> > Can you clarify ?
>> > There is an executor pool (max size : 1 for now) and a
>> >
>> > socketOutputStreamPool in GraphiteMetricsManager.
>>
>> Sorry, that was wrong.
>>
>> There's a socketOutputStreamPool in PickleMetricsManager only
>> I thought I had spotted another in SocketOutputStreamPoolFactory but
>> that is just the implementation.
>>
>> >
>> > How many of these would there be?
>> >>
>> >
>> > Currently it is true we could use only one socket and keep it open.
>> >
>> >
>> >>
>> >> Also, DescriptiveStatistics is not thread-safe (nor is StatCalculator).
>> >>
>> > It is not a problem, as DescriptiveStatistics is accessed synchronously.
>>
>> Only write accesses are synchronised.
>> But read needs to be synchronised as well to ensure safe publication.
>>
>> >>
>> >> If we do implement something like this, I think the data processing
>> needs
>> >> either to be carefully synchronised, or the raw data should be sent to a
>> >> separate singleton background thread.
>> >>
>> >
>> > I think it is carefully synchronized in the patch. If not please point me
>> > to where you see an issue.
>>
>> See above.
>>
>> If it used a background thread with a suitable queuing mechanism,
>> there would be no need to synch the data collection, and the
>> processing would not slow the main thread.
>>
> So you mean we publish the SampleResult in a queue and a thread handles
> computation ?
Yes.
We would need to define a suitable API (interface) here so that
different implementations can be plugged in.
> Do you intend to implement a kind of RingBuffer , something like this :
> https://github.com/LMAX-Exchange/disruptor
> or much simpler ?
I was thinking of one of the standard Java queues like we already use
for returning samples in client server mode.
But it might be worth looking at disruptor.
> And is there another thread to send ?
Probably not necessary, and might be counter-productive as it would
likely need additonal sync and another queue.
> Could you propose a patch change ?
>
>
>
>>
>> What happens currently if the backend socket stalls or runs slowly?
>>
> It will only affect the publication .
> The run method will be executed while the other one is still running , so
> we could send same statistics twice, good catch.
>
>
>>
>> Also, decoupling in this way would make it easier to provide
>> implementations, as they would not need to be thread-safe.
>>
>> >
>> >>
>> >> Follow-ups to the dev list please.
>> >>
>> >> --
>> >> You are receiving this mail because:
>> >> You are the assignee for the bug.
>> >>
>> >
>> >
>> >
>> > --
>> > Cordialement.
>> > Philippe Mouawad.
>>
>
>
>
> --
> Cordialement.
> Philippe Mouawad.
Re: [Bug 55932] Create a Graphite Listener
Posted by Philippe Mouawad <ph...@gmail.com>.
On Fri, Jan 3, 2014 at 3:33 PM, sebb <se...@gmail.com> wrote:
> On 3 January 2014 13:47, Philippe Mouawad <ph...@gmail.com>
> wrote:
> > Hello Sebb,
> > As requested although I don't see why it cannot be in bugzilla,if it were
> > the history of discussion could be found more easily.
>
> Because discussion may take a while and Bugzilla is not good for that.
> We can add links to the mail thread with any followup, once decisions are
> made.
>
> > Regards
> > Philippe
> > On Fri, Jan 3, 2014 at 1:57 PM, <bu...@apache.org> wrote:
> >
> >> https://issues.apache.org/bugzilla/show_bug.cgi?id=55932
> >>
> >> --- Comment #6 from Sebb <se...@apache.org> ---
> >> I have been having a look at the implementation.
> >>
> >> I don't really see that it needs Commons Math; we aleady have
> >> StatCalculator
> >> which handles percentiles and more.
> >>
> > Ok I can change this.
> >
> >>
> >> Likewise, does it really need Commons Pool?
> >> It seems wrong to have to have 2 separate pools of SocketOutputStream
> >> instances.
> >>
> > Can you clarify ?
> > There is an executor pool (max size : 1 for now) and a
> >
> > socketOutputStreamPool in GraphiteMetricsManager.
>
> Sorry, that was wrong.
>
> There's a socketOutputStreamPool in PickleMetricsManager only
> I thought I had spotted another in SocketOutputStreamPoolFactory but
> that is just the implementation.
>
> >
> > How many of these would there be?
> >>
> >
> > Currently it is true we could use only one socket and keep it open.
> >
> >
> >>
> >> Also, DescriptiveStatistics is not thread-safe (nor is StatCalculator).
> >>
> > It is not a problem, as DescriptiveStatistics is accessed synchronously.
>
> Only write accesses are synchronised.
> But read needs to be synchronised as well to ensure safe publication.
>
> >>
> >> If we do implement something like this, I think the data processing
> needs
> >> either to be carefully synchronised, or the raw data should be sent to a
> >> separate singleton background thread.
> >>
> >
> > I think it is carefully synchronized in the patch. If not please point me
> > to where you see an issue.
>
> See above.
>
> If it used a background thread with a suitable queuing mechanism,
> there would be no need to synch the data collection, and the
> processing would not slow the main thread.
>
So you mean we publish the SampleResult in a queue and a thread handles
computation ?
Do you intend to implement a kind of RingBuffer , something like this :
https://github.com/LMAX-Exchange/disruptor
or much simpler ?
And is there another thread to send ?
Could you propose a patch change ?
>
> What happens currently if the backend socket stalls or runs slowly?
>
It will only affect the publication .
The run method will be executed while the other one is still running , so
we could send same statistics twice, good catch.
>
> Also, decoupling in this way would make it easier to provide
> implementations, as they would not need to be thread-safe.
>
> >
> >>
> >> Follow-ups to the dev list please.
> >>
> >> --
> >> You are receiving this mail because:
> >> You are the assignee for the bug.
> >>
> >
> >
> >
> > --
> > Cordialement.
> > Philippe Mouawad.
>
--
Cordialement.
Philippe Mouawad.
Re: [Bug 55932] Create a Graphite Listener
Posted by sebb <se...@gmail.com>.
On 3 January 2014 13:47, Philippe Mouawad <ph...@gmail.com> wrote:
> Hello Sebb,
> As requested although I don't see why it cannot be in bugzilla,if it were
> the history of discussion could be found more easily.
Because discussion may take a while and Bugzilla is not good for that.
We can add links to the mail thread with any followup, once decisions are made.
> Regards
> Philippe
> On Fri, Jan 3, 2014 at 1:57 PM, <bu...@apache.org> wrote:
>
>> https://issues.apache.org/bugzilla/show_bug.cgi?id=55932
>>
>> --- Comment #6 from Sebb <se...@apache.org> ---
>> I have been having a look at the implementation.
>>
>> I don't really see that it needs Commons Math; we aleady have
>> StatCalculator
>> which handles percentiles and more.
>>
> Ok I can change this.
>
>>
>> Likewise, does it really need Commons Pool?
>> It seems wrong to have to have 2 separate pools of SocketOutputStream
>> instances.
>>
> Can you clarify ?
> There is an executor pool (max size : 1 for now) and a
>
> socketOutputStreamPool in GraphiteMetricsManager.
Sorry, that was wrong.
There's a socketOutputStreamPool in PickleMetricsManager only
I thought I had spotted another in SocketOutputStreamPoolFactory but
that is just the implementation.
>
> How many of these would there be?
>>
>
> Currently it is true we could use only one socket and keep it open.
>
>
>>
>> Also, DescriptiveStatistics is not thread-safe (nor is StatCalculator).
>>
> It is not a problem, as DescriptiveStatistics is accessed synchronously.
Only write accesses are synchronised.
But read needs to be synchronised as well to ensure safe publication.
>>
>> If we do implement something like this, I think the data processing needs
>> either to be carefully synchronised, or the raw data should be sent to a
>> separate singleton background thread.
>>
>
> I think it is carefully synchronized in the patch. If not please point me
> to where you see an issue.
See above.
If it used a background thread with a suitable queuing mechanism,
there would be no need to synch the data collection, and the
processing would not slow the main thread.
What happens currently if the backend socket stalls or runs slowly?
Also, decoupling in this way would make it easier to provide
implementations, as they would not need to be thread-safe.
>
>>
>> Follow-ups to the dev list please.
>>
>> --
>> You are receiving this mail because:
>> You are the assignee for the bug.
>>
>
>
>
> --
> Cordialement.
> Philippe Mouawad.
Re: [Bug 55932] Create a Graphite Listener
Posted by Philippe Mouawad <ph...@gmail.com>.
Hello Sebb,
As requested although I don't see why it cannot be in bugzilla,if it were
the history of discussion could be found more easily.
Regards
Philippe
On Fri, Jan 3, 2014 at 1:57 PM, <bu...@apache.org> wrote:
> https://issues.apache.org/bugzilla/show_bug.cgi?id=55932
>
> --- Comment #6 from Sebb <se...@apache.org> ---
> I have been having a look at the implementation.
>
> I don't really see that it needs Commons Math; we aleady have
> StatCalculator
> which handles percentiles and more.
>
Ok I can change this.
>
> Likewise, does it really need Commons Pool?
> It seems wrong to have to have 2 separate pools of SocketOutputStream
> instances.
>
Can you clarify ?
There is an executor pool (max size : 1 for now) and a
socketOutputStreamPool in GraphiteMetricsManager.
How many of these would there be?
>
Currently it is true we could use only one socket and keep it open.
>
> Also, DescriptiveStatistics is not thread-safe (nor is StatCalculator).
>
It is not a problem, as DescriptiveStatistics is accessed synchronously.
>
> If we do implement something like this, I think the data processing needs
> either to be carefully synchronised, or the raw data should be sent to a
> separate singleton background thread.
>
I think it is carefully synchronized in the patch. If not please point me
to where you see an issue.
>
> Follow-ups to the dev list please.
>
> --
> You are receiving this mail because:
> You are the assignee for the bug.
>
--
Cordialement.
Philippe Mouawad.
Re: [Bug 55932] Create a Graphite Listener
Posted by sebb <se...@gmail.com>.
On 3 January 2014 22:58, Rainer Jung <ra...@kippdata.de> wrote:
> On 03.01.2014 13:57, bugzilla@apache.org wrote:
>> https://issues.apache.org/bugzilla/show_bug.cgi?id=55932
>>
>> --- Comment #6 from Sebb <se...@apache.org> ---
>> I have been having a look at the implementation.
>>
>> I don't really see that it needs Commons Math; we aleady have StatCalculator
>> which handles percentiles and more.
>>
>> Likewise, does it really need Commons Pool?
>> It seems wrong to have to have 2 separate pools of SocketOutputStream
>> instances.
>> How many of these would there be?
>>
>> Also, DescriptiveStatistics is not thread-safe (nor is StatCalculator).
>>
>> If we do implement something like this, I think the data processing needs
>> either to be carefully synchronised, or the raw data should be sent to a
>> separate singleton background thread.
>
> FWIW: I always get a bit nervous when percentiles are calculated.
> Percentiles are expensive to calculate if one needs exact results with
> given percentage numbers (50%, 99%, 99.9% etc.). In that case one needs
> to keep all values as an ordered list to calculate the percentiles. For
> a long running test that would be expensive in terms of memory but also
> in terms of CPU (sorting). There's no way of exactly merging percentiles
> from interim statistical data.
>
> Sometimes approximations are enough. By approximation I don't mean
> estimated data, but percentages which are not exactly the ones you are
> keen for. E.g. you would get a 48% value instead of a 50% value, or a
> 99.02% value instead of a 99% value.
>
> Suppose you would know (configure) that only very few samples will take
> longer than 1000ms, then one could create fixed bins for e.g. 10ms,
> 15ms, 20ms, 25ms, 30ms, 40ms, 50ms, 75ms, 100ms, 150ms, 200ms, 250ms,
> 300ms, 400ms, 500ms, 750ms and 1000ms. Now whenever a sample finishes
> you count the sample in the bin it belongs to and do not save the data
> (of course you can still log it). At any time you can now look at the
> not need to keep all sample values around and sort them, but one does
> also not get equidistant percentiles (10%, 11%, 12%, ...).
StatCalculator already takes a similar approach, counting values
rather than storing them.
We already use it for the GUI listeners.
There are other approaches; Commons Math DescriptiveStatistics uses an
array of doubles (with a sliding window).
And there is also the following:
http://search-lucene.com/jd/mahout/math/org/apache/mahout/math/stats/OnlineSummarizer.html
However, AFAICT it does not support arbitrary percentiles, only quartiles.
Re: [Bug 55932] Create a Graphite Listener
Posted by sebb <se...@gmail.com>.
On 3 January 2014 23:22, Philippe Mouawad <ph...@gmail.com> wrote:
> Thanks Rainer, of great help!
> Regarding graphite, it offers a function to compute percentiles, so we
> could as sebb proposed it send raw results.
No, I was not proposing that.
I did not know that Graphite could do the calculations.
I was proposing that the calculations were done in the back-end thread
before sending to graphite.
The point was to separate the collection and processing of the data.
However it would be nice if graphite supported aggregated data, that
could reduce the amount to be sent to it.
> My concern was about the memory and network impact of sending all sample
> results to backend.
Likewise.
> So should we create what you propose, do you know an existing library that
> implements it already ?
See my reply to Rainer.
StatCalculator does it already.
>
> On Friday, January 3, 2014, Rainer Jung wrote:
>
>> On 03.01.2014 13:57, bugzilla@apache.org <javascript:;> wrote:
>> > https://issues.apache.org/bugzilla/show_bug.cgi?id=55932
>> >
>> > --- Comment #6 from Sebb <sebb@apache.org <javascript:;>> ---
>> > I have been having a look at the implementation.
>> >
>> > I don't really see that it needs Commons Math; we aleady have
>> StatCalculator
>> > which handles percentiles and more.
>> >
>> > Likewise, does it really need Commons Pool?
>> > It seems wrong to have to have 2 separate pools of SocketOutputStream
>> > instances.
>> > How many of these would there be?
>> >
>> > Also, DescriptiveStatistics is not thread-safe (nor is StatCalculator).
>> >
>> > If we do implement something like this, I think the data processing needs
>> > either to be carefully synchronised, or the raw data should be sent to a
>> > separate singleton background thread.
>>
>> FWIW: I always get a bit nervous when percentiles are calculated.
>> Percentiles are expensive to calculate if one needs exact results with
>> given percentage numbers (50%, 99%, 99.9% etc.). In that case one needs
>> to keep all values as an ordered list to calculate the percentiles. For
>> a long running test that would be expensive in terms of memory but also
>> in terms of CPU (sorting). There's no way of exactly merging percentiles
>> from interim statistical data.
>>
>> Sometimes approximations are enough. By approximation I don't mean
>> estimated data, but percentages which are not exactly the ones you are
>> keen for. E.g. you would get a 48% value instead of a 50% value, or a
>> 99.02% value instead of a 99% value.
>>
>> Suppose you would know (configure) that only very few samples will take
>> longer than 1000ms, then one could create fixed bins for e.g. 10ms,
>> 15ms, 20ms, 25ms, 30ms, 40ms, 50ms, 75ms, 100ms, 150ms, 200ms, 250ms,
>> 300ms, 400ms, 500ms, 750ms and 1000ms. Now whenever a sample finishes
>> you count the sample in the bin it belongs to and do not save the data
>> (of course you can still log it). At any time you can now look at the
>> bin counters and cheaply produce quantiles. For example suppose the bin
>> counters look like that:
>>
>> Duration binCount
>> 10ms 3
>> 15ms 2
>> 20ms 5
>> 25ms 10
>> 30ms 8
>> 40ms 20
>> 50ms 28
>> 75ms 100
>> 100ms 230
>> 150ms 610
>> 200ms 780
>> 250ms 530
>> 300ms 220
>> 400ms 200
>> 500ms 80
>> 750ms 90
>> 1000ms 50
>> >1000ms 30
>>
>> Now we sum up the bin count into cumulated count and take percentages:
>>
>> Duration binCount Cum. Cum.Pct binPct
>> 10ms 3 3 0.10% 0.10%
>> 15ms 2 5 0.17% 0.07%
>> 20ms 5 10 0.33% 0.17%
>> 25ms 10 20 0.67% 0.33%
>> 30ms 8 28 0.93% 0.27%
>> 40ms 20 48 1.60% 0.67%
>> 50ms 28 76 2.54% 0.93%
>> 75ms 100 176 5.87% 3.34%
>> 100ms 230 406 13.55% 7.68%
>> 150ms 610 1016 33.91% 20.36%
>> 200ms 780 1796 59.95% 26.03%
>> 250ms 530 2326 77.64% 17.69%
>> 300ms 220 2546 84.98% 7.34%
>> 400ms 200 2746 91.66% 6.68%
>> 500ms 80 2826 94.33% 2.67%
>> 750ms 90 2916 97.33% 3.00%
>> 1000ms 50 2966 99.00% 1.67%
>> >1000ms 30 2996 100.00% 1.00%
>>
>> The Cum.Pct column could be used instead of the percentiles. One does
>> not need to keep all sample values around and sort them, but one does
>> also not get equidistant percentiles (10%, 11%, 12%, ...).
>>
>> Making the table more fine grained by using more rows is cheap. I have
>> chosen here a short table to make the example easier to understand. The
>> duration limits for the bins I had chosen were human friendly (integral
>> numbers, often divisible by 10 or 100), but one could also use a
>> mathematically strict series like e.g. 100 logarithmic steps or 10
>> logarithmic steps for each factor 10 in duration time. The bin limits
>> would then increase by 26% from bin to bin, e.g. 100ms, 126ms, 158ms,
>> 200ms, 251ms, 316ms, 398ms, 501ms, 631ms, 794ms, 1000ms.
>>
>> Users who need integral percentiles, like exactly 50% or 99% values
>> instead of 48.2% or 99.05% values (example) would need to either post
>> process the sample logs or choose a more expensive live processing (in
>> terms of memory and cpu be it inside JMeter or another backend). I'd
>> expect, that often the non-integral percentiles above are good enough to
>> follow a running test and get sufficient data about its behavior (and
>> are cheap enough to produce on the fly) and the integral percentiles are
>> OK to generate during post-processing and full report generation after a
>> run.
>>
>> Just my 2c.
>>
>> Regards,
>>
>> Rainer
>>
>
>
> --
> Cordialement.
> Philippe Mouawad.
Re: [Bug 55932] Create a Graphite Listener
Posted by Philippe Mouawad <ph...@gmail.com>.
Thanks Rainer, of great help!
Regarding graphite, it offers a function to compute percentiles, so we
could as sebb proposed it send raw results.
My concern was about the memory and network impact of sending all sample
results to backend.
So should we create what you propose, do you know an existing library that
implements it already ?
On Friday, January 3, 2014, Rainer Jung wrote:
> On 03.01.2014 13:57, bugzilla@apache.org <javascript:;> wrote:
> > https://issues.apache.org/bugzilla/show_bug.cgi?id=55932
> >
> > --- Comment #6 from Sebb <sebb@apache.org <javascript:;>> ---
> > I have been having a look at the implementation.
> >
> > I don't really see that it needs Commons Math; we aleady have
> StatCalculator
> > which handles percentiles and more.
> >
> > Likewise, does it really need Commons Pool?
> > It seems wrong to have to have 2 separate pools of SocketOutputStream
> > instances.
> > How many of these would there be?
> >
> > Also, DescriptiveStatistics is not thread-safe (nor is StatCalculator).
> >
> > If we do implement something like this, I think the data processing needs
> > either to be carefully synchronised, or the raw data should be sent to a
> > separate singleton background thread.
>
> FWIW: I always get a bit nervous when percentiles are calculated.
> Percentiles are expensive to calculate if one needs exact results with
> given percentage numbers (50%, 99%, 99.9% etc.). In that case one needs
> to keep all values as an ordered list to calculate the percentiles. For
> a long running test that would be expensive in terms of memory but also
> in terms of CPU (sorting). There's no way of exactly merging percentiles
> from interim statistical data.
>
> Sometimes approximations are enough. By approximation I don't mean
> estimated data, but percentages which are not exactly the ones you are
> keen for. E.g. you would get a 48% value instead of a 50% value, or a
> 99.02% value instead of a 99% value.
>
> Suppose you would know (configure) that only very few samples will take
> longer than 1000ms, then one could create fixed bins for e.g. 10ms,
> 15ms, 20ms, 25ms, 30ms, 40ms, 50ms, 75ms, 100ms, 150ms, 200ms, 250ms,
> 300ms, 400ms, 500ms, 750ms and 1000ms. Now whenever a sample finishes
> you count the sample in the bin it belongs to and do not save the data
> (of course you can still log it). At any time you can now look at the
> bin counters and cheaply produce quantiles. For example suppose the bin
> counters look like that:
>
> Duration binCount
> 10ms 3
> 15ms 2
> 20ms 5
> 25ms 10
> 30ms 8
> 40ms 20
> 50ms 28
> 75ms 100
> 100ms 230
> 150ms 610
> 200ms 780
> 250ms 530
> 300ms 220
> 400ms 200
> 500ms 80
> 750ms 90
> 1000ms 50
> >1000ms 30
>
> Now we sum up the bin count into cumulated count and take percentages:
>
> Duration binCount Cum. Cum.Pct binPct
> 10ms 3 3 0.10% 0.10%
> 15ms 2 5 0.17% 0.07%
> 20ms 5 10 0.33% 0.17%
> 25ms 10 20 0.67% 0.33%
> 30ms 8 28 0.93% 0.27%
> 40ms 20 48 1.60% 0.67%
> 50ms 28 76 2.54% 0.93%
> 75ms 100 176 5.87% 3.34%
> 100ms 230 406 13.55% 7.68%
> 150ms 610 1016 33.91% 20.36%
> 200ms 780 1796 59.95% 26.03%
> 250ms 530 2326 77.64% 17.69%
> 300ms 220 2546 84.98% 7.34%
> 400ms 200 2746 91.66% 6.68%
> 500ms 80 2826 94.33% 2.67%
> 750ms 90 2916 97.33% 3.00%
> 1000ms 50 2966 99.00% 1.67%
> >1000ms 30 2996 100.00% 1.00%
>
> The Cum.Pct column could be used instead of the percentiles. One does
> not need to keep all sample values around and sort them, but one does
> also not get equidistant percentiles (10%, 11%, 12%, ...).
>
> Making the table more fine grained by using more rows is cheap. I have
> chosen here a short table to make the example easier to understand. The
> duration limits for the bins I had chosen were human friendly (integral
> numbers, often divisible by 10 or 100), but one could also use a
> mathematically strict series like e.g. 100 logarithmic steps or 10
> logarithmic steps for each factor 10 in duration time. The bin limits
> would then increase by 26% from bin to bin, e.g. 100ms, 126ms, 158ms,
> 200ms, 251ms, 316ms, 398ms, 501ms, 631ms, 794ms, 1000ms.
>
> Users who need integral percentiles, like exactly 50% or 99% values
> instead of 48.2% or 99.05% values (example) would need to either post
> process the sample logs or choose a more expensive live processing (in
> terms of memory and cpu be it inside JMeter or another backend). I'd
> expect, that often the non-integral percentiles above are good enough to
> follow a running test and get sufficient data about its behavior (and
> are cheap enough to produce on the fly) and the integral percentiles are
> OK to generate during post-processing and full report generation after a
> run.
>
> Just my 2c.
>
> Regards,
>
> Rainer
>
--
Cordialement.
Philippe Mouawad.
Re: [Bug 55932] Create a Graphite Listener
Posted by Rainer Jung <ra...@kippdata.de>.
On 03.01.2014 13:57, bugzilla@apache.org wrote:
> https://issues.apache.org/bugzilla/show_bug.cgi?id=55932
>
> --- Comment #6 from Sebb <se...@apache.org> ---
> I have been having a look at the implementation.
>
> I don't really see that it needs Commons Math; we aleady have StatCalculator
> which handles percentiles and more.
>
> Likewise, does it really need Commons Pool?
> It seems wrong to have to have 2 separate pools of SocketOutputStream
> instances.
> How many of these would there be?
>
> Also, DescriptiveStatistics is not thread-safe (nor is StatCalculator).
>
> If we do implement something like this, I think the data processing needs
> either to be carefully synchronised, or the raw data should be sent to a
> separate singleton background thread.
FWIW: I always get a bit nervous when percentiles are calculated.
Percentiles are expensive to calculate if one needs exact results with
given percentage numbers (50%, 99%, 99.9% etc.). In that case one needs
to keep all values as an ordered list to calculate the percentiles. For
a long running test that would be expensive in terms of memory but also
in terms of CPU (sorting). There's no way of exactly merging percentiles
from interim statistical data.
Sometimes approximations are enough. By approximation I don't mean
estimated data, but percentages which are not exactly the ones you are
keen for. E.g. you would get a 48% value instead of a 50% value, or a
99.02% value instead of a 99% value.
Suppose you would know (configure) that only very few samples will take
longer than 1000ms, then one could create fixed bins for e.g. 10ms,
15ms, 20ms, 25ms, 30ms, 40ms, 50ms, 75ms, 100ms, 150ms, 200ms, 250ms,
300ms, 400ms, 500ms, 750ms and 1000ms. Now whenever a sample finishes
you count the sample in the bin it belongs to and do not save the data
(of course you can still log it). At any time you can now look at the
bin counters and cheaply produce quantiles. For example suppose the bin
counters look like that:
Duration binCount
10ms 3
15ms 2
20ms 5
25ms 10
30ms 8
40ms 20
50ms 28
75ms 100
100ms 230
150ms 610
200ms 780
250ms 530
300ms 220
400ms 200
500ms 80
750ms 90
1000ms 50
>1000ms 30
Now we sum up the bin count into cumulated count and take percentages:
Duration binCount Cum. Cum.Pct binPct
10ms 3 3 0.10% 0.10%
15ms 2 5 0.17% 0.07%
20ms 5 10 0.33% 0.17%
25ms 10 20 0.67% 0.33%
30ms 8 28 0.93% 0.27%
40ms 20 48 1.60% 0.67%
50ms 28 76 2.54% 0.93%
75ms 100 176 5.87% 3.34%
100ms 230 406 13.55% 7.68%
150ms 610 1016 33.91% 20.36%
200ms 780 1796 59.95% 26.03%
250ms 530 2326 77.64% 17.69%
300ms 220 2546 84.98% 7.34%
400ms 200 2746 91.66% 6.68%
500ms 80 2826 94.33% 2.67%
750ms 90 2916 97.33% 3.00%
1000ms 50 2966 99.00% 1.67%
>1000ms 30 2996 100.00% 1.00%
The Cum.Pct column could be used instead of the percentiles. One does
not need to keep all sample values around and sort them, but one does
also not get equidistant percentiles (10%, 11%, 12%, ...).
Making the table more fine grained by using more rows is cheap. I have
chosen here a short table to make the example easier to understand. The
duration limits for the bins I had chosen were human friendly (integral
numbers, often divisible by 10 or 100), but one could also use a
mathematically strict series like e.g. 100 logarithmic steps or 10
logarithmic steps for each factor 10 in duration time. The bin limits
would then increase by 26% from bin to bin, e.g. 100ms, 126ms, 158ms,
200ms, 251ms, 316ms, 398ms, 501ms, 631ms, 794ms, 1000ms.
Users who need integral percentiles, like exactly 50% or 99% values
instead of 48.2% or 99.05% values (example) would need to either post
process the sample logs or choose a more expensive live processing (in
terms of memory and cpu be it inside JMeter or another backend). I'd
expect, that often the non-integral percentiles above are good enough to
follow a running test and get sufficient data about its behavior (and
are cheap enough to produce on the fly) and the integral percentiles are
OK to generate during post-processing and full report generation after a
run.
Just my 2c.
Regards,
Rainer
[Bug 55932] Create a Graphite Listener
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55932
--- Comment #6 from Sebb <se...@apache.org> ---
I have been having a look at the implementation.
I don't really see that it needs Commons Math; we aleady have StatCalculator
which handles percentiles and more.
Likewise, does it really need Commons Pool?
It seems wrong to have to have 2 separate pools of SocketOutputStream
instances.
How many of these would there be?
Also, DescriptiveStatistics is not thread-safe (nor is StatCalculator).
If we do implement something like this, I think the data processing needs
either to be carefully synchronised, or the raw data should be sent to a
separate singleton background thread.
Follow-ups to the dev list please.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 55932] Create a Async BackendListener to allow easy plug of new
listener (Graphite, JDBC, Console,...)
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55932
Philippe Mouawad <p....@ubik-ingenierie.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|REOPENED |RESOLVED
Resolution|--- |FIXED
--- Comment #12 from Philippe Mouawad <p....@ubik-ingenierie.com> ---
Date: Sun Nov 30 19:35:07 2014
New Revision: 1642600
URL: http://svn.apache.org/r1642600
Log:
Store queue size as a String (allows use of variables etc)
Modified:
jmeter/trunk/src/components/org/apache/jmeter/visualizers/backend/BackendListener.java
jmeter/trunk/src/components/org/apache/jmeter/visualizers/backend/BackendListenerGui.java
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 55932] Create a Async BackendListener to allow easy plug of new
listener (Graphite, JDBC, Console,...)
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55932
--- Comment #9 from Philippe Mouawad <p....@ubik-ingenierie.com> ---
Date: Sat Nov 22 15:55:27 2014
New Revision: 1641086
URL: http://svn.apache.org/r1641086
Log:
Bug 55932 - Create a Async BackendListener to allow easy plug of new listener
(Graphite, JDBC, Console,...)
Fix mistake in imports
Bugzilla Id: 55932
Modified:
jmeter/trunk/src/components/org/apache/jmeter/visualizers/backend/BackendListener.java
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 55932] Create a Graphite Listener
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55932
Philippe Mouawad <p....@ubik-ingenierie.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |p.mouawad@ubik-ingenierie.c
| |om
--- Comment #1 from Philippe Mouawad <p....@ubik-ingenierie.com> ---
Created attachment 31155
--> https://issues.apache.org/bugzilla/attachment.cgi?id=31155&action=edit
Implementation
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 55932] Create a Graphite Listener
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55932
--- Comment #4 from Milamber <mi...@apache.org> ---
Created attachment 31166
--> https://issues.apache.org/bugzilla/attachment.cgi?id=31166&action=edit
Elements list with my test
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 55932] Create a Async BackendListener to allow easy plug of new
listener (Graphite, JDBC, Console,...)
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55932
--- Comment #10 from Philippe Mouawad <p....@ubik-ingenierie.com> ---
Date: Sat Nov 22 20:01:50 2014
New Revision: 1641118
URL: http://svn.apache.org/r1641118
Log:
Bug 55932 - Create a Async BackendListener to allow easy plug of new listener
(Graphite, JDBC, Console,...)
Fix javadocs , naming
But more importantly fix multi-threading issues on instance variables as there
is only 1 BackendListener shared by all threads
Bugzilla Id: 55932
Modified:
jmeter/trunk/src/components/org/apache/jmeter/visualizers/backend/BackendListener.java
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 55932] Create a Graphite Listener
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55932
--- Comment #3 from Milamber <mi...@apache.org> ---
(missing doc reference, saveservice, ...)
[java] Created: 89 tests including 8 suites
[java] Starting test run, test count = 2530
[java] .......................................F..
[java] .........................................
[java] .........................................
[java] .........................................
[java] .........................................
[java] .........................................
[java] .........................................
[java] .........................................
[java] .........................................
[java] .........................................
[java] .........................................
[java] .........................................
[java] .........................................
[java] .........................................
[java] .........................................
[java] .........................................
[java] .........................................
[java] .........................................
[java] .........................................
[java] .........................................
[java] .........................................
[java] .........................................
[java] .........................................
[java] .........................................
[java] .........................................
[java] .........................................
[java] .........................................
[java] .........F................................
[java] .........................................
[java] ..F.......................................
[java] .........................................
[java] .........................................
[java] .........................................
[java] .........................................
[java] .........................................
[java] .........................................
[java] .........................................
[java] .........................................
[java] .........................................
[java] .........................................
[java] .........................................
[java] .........................................
[java] .........................................
[java] .........................................
[java] .........................................
[java] .........................................
[java] .........................................
[java] .........................................
[java] .........................................
[java] .........................................
[java] .........................................
[java] .........................................
[java] .........................................
[java] .........................................
[java] .........................................
[java] .........................................
[java] ........................E.E..E.E.E.E.E.E.E.E.E......
[java] .........................................
[java] .........................................
[java] .........................................
[java] .........................................
[java] .............................
[java] Time: 77.02
[java] There were 11 errors:
[java] 1) org.apache.jmeter.reporters.graphite.GraphiteListener - en -
(org.apache.jmeter.testbeans.gui.PackageTest)java.util.MissingResourceException:
Can't find resource for bundle java.util.PropertyResourceBundle, key
graphiteHost.displayName
[java] at java.util.ResourceBundle.getObject(ResourceBundle.java:374)
[java] at java.util.ResourceBundle.getString(ResourceBundle.java:334)
[java] at
org.apache.jmeter.testbeans.gui.PackageTest.checkAllNecessaryKeysPresent(PackageTest.java:157)
[java] at
org.apache.jmeter.testbeans.gui.PackageTest.runTest(PackageTest.java:112)
[java] at org.apache.jorphan.test.AllTests.main(AllTests.java:236)
[java] 2) org.apache.jmeter.reporters.graphite.GraphiteListener - en -
(org.apache.jmeter.testbeans.gui.PackageTest)java.util.MissingResourceException:
Can't find resource for bundle java.util.PropertyResourceBundle, key
graphiteHost.displayName
[java] at java.util.ResourceBundle.getObject(ResourceBundle.java:374)
[java] at java.util.ResourceBundle.getString(ResourceBundle.java:334)
[java] at
org.apache.jmeter.testbeans.gui.PackageTest.checkAllNecessaryKeysPresent(PackageTest.java:157)
[java] at
org.apache.jmeter.testbeans.gui.PackageTest.runTest(PackageTest.java:112)
[java] at org.apache.jorphan.test.AllTests.main(AllTests.java:236)
[java] 3) org.apache.jmeter.reporters.graphite.GraphiteListener - de -
(org.apache.jmeter.testbeans.gui.PackageTest)java.util.MissingResourceException:
Can't find resource for bundle java.util.PropertyResourceBundle, key
graphiteHost.displayName
[java] at java.util.ResourceBundle.getObject(ResourceBundle.java:374)
[java] at java.util.ResourceBundle.getString(ResourceBundle.java:334)
[java] at
org.apache.jmeter.testbeans.gui.PackageTest.checkAllNecessaryKeysPresent(PackageTest.java:157)
[java] at
org.apache.jmeter.testbeans.gui.PackageTest.runTest(PackageTest.java:112)
[java] at org.apache.jorphan.test.AllTests.main(AllTests.java:236)
[java] 4) org.apache.jmeter.reporters.graphite.GraphiteListener - no -
(org.apache.jmeter.testbeans.gui.PackageTest)java.util.MissingResourceException:
Can't find resource for bundle java.util.PropertyResourceBundle, key
graphiteHost.displayName
[java] at java.util.ResourceBundle.getObject(ResourceBundle.java:374)
[java] at java.util.ResourceBundle.getString(ResourceBundle.java:334)
[java] at
org.apache.jmeter.testbeans.gui.PackageTest.checkAllNecessaryKeysPresent(PackageTest.java:157)
[java] at
org.apache.jmeter.testbeans.gui.PackageTest.runTest(PackageTest.java:112)
[java] at org.apache.jorphan.test.AllTests.main(AllTests.java:236)
[java] 5) org.apache.jmeter.reporters.graphite.GraphiteListener - pl -
(org.apache.jmeter.testbeans.gui.PackageTest)java.util.MissingResourceException:
Can't find resource for bundle java.util.PropertyResourceBundle, key
graphiteHost.displayName
[java] at java.util.ResourceBundle.getObject(ResourceBundle.java:374)
[java] at java.util.ResourceBundle.getString(ResourceBundle.java:334)
[java] at
org.apache.jmeter.testbeans.gui.PackageTest.checkAllNecessaryKeysPresent(PackageTest.java:157)
[java] at
org.apache.jmeter.testbeans.gui.PackageTest.runTest(PackageTest.java:112)
[java] at org.apache.jorphan.test.AllTests.main(AllTests.java:236)
[java] 6) org.apache.jmeter.reporters.graphite.GraphiteListener - pt -
BR(org.apache.jmeter.testbeans.gui.PackageTest)java.util.MissingResourceException:
Can't find resource for bundle java.util.PropertyResourceBundle, key
graphiteHost.displayName
[java] at java.util.ResourceBundle.getObject(ResourceBundle.java:374)
[java] at java.util.ResourceBundle.getString(ResourceBundle.java:334)
[java] at
org.apache.jmeter.testbeans.gui.PackageTest.checkAllNecessaryKeysPresent(PackageTest.java:157)
[java] at
org.apache.jmeter.testbeans.gui.PackageTest.runTest(PackageTest.java:112)
[java] at org.apache.jorphan.test.AllTests.main(AllTests.java:236)
[java] 7) org.apache.jmeter.reporters.graphite.GraphiteListener - es -
(org.apache.jmeter.testbeans.gui.PackageTest)java.util.MissingResourceException:
Can't find resource for bundle java.util.PropertyResourceBundle, key
graphiteHost.displayName
[java] at java.util.ResourceBundle.getObject(ResourceBundle.java:374)
[java] at java.util.ResourceBundle.getString(ResourceBundle.java:334)
[java] at
org.apache.jmeter.testbeans.gui.PackageTest.checkAllNecessaryKeysPresent(PackageTest.java:157)
[java] at
org.apache.jmeter.testbeans.gui.PackageTest.runTest(PackageTest.java:112)
[java] at org.apache.jorphan.test.AllTests.main(AllTests.java:236)
[java] 8) org.apache.jmeter.reporters.graphite.GraphiteListener - tr -
(org.apache.jmeter.testbeans.gui.PackageTest)java.util.MissingResourceException:
Can't find resource for bundle java.util.PropertyResourceBundle, key
graphiteHost.displayName
[java] at java.util.ResourceBundle.getObject(ResourceBundle.java:374)
[java] at java.util.ResourceBundle.getString(ResourceBundle.java:334)
[java] at
org.apache.jmeter.testbeans.gui.PackageTest.checkAllNecessaryKeysPresent(PackageTest.java:157)
[java] at
org.apache.jmeter.testbeans.gui.PackageTest.runTest(PackageTest.java:112)
[java] at org.apache.jorphan.test.AllTests.main(AllTests.java:236)
[java] 9) org.apache.jmeter.reporters.graphite.GraphiteListener - ja -
(org.apache.jmeter.testbeans.gui.PackageTest)java.util.MissingResourceException:
Can't find resource for bundle java.util.PropertyResourceBundle, key
graphiteHost.displayName
[java] at java.util.ResourceBundle.getObject(ResourceBundle.java:374)
[java] at java.util.ResourceBundle.getString(ResourceBundle.java:334)
[java] at
org.apache.jmeter.testbeans.gui.PackageTest.checkAllNecessaryKeysPresent(PackageTest.java:157)
[java] at
org.apache.jmeter.testbeans.gui.PackageTest.runTest(PackageTest.java:112)
[java] at org.apache.jorphan.test.AllTests.main(AllTests.java:236)
[java] 10) org.apache.jmeter.reporters.graphite.GraphiteListener - zh -
CN(org.apache.jmeter.testbeans.gui.PackageTest)java.util.MissingResourceException:
Can't find resource for bundle java.util.PropertyResourceBundle, key
graphiteHost.displayName
[java] at java.util.ResourceBundle.getObject(ResourceBundle.java:374)
[java] at java.util.ResourceBundle.getString(ResourceBundle.java:334)
[java] at
org.apache.jmeter.testbeans.gui.PackageTest.checkAllNecessaryKeysPresent(PackageTest.java:157)
[java] at
org.apache.jmeter.testbeans.gui.PackageTest.runTest(PackageTest.java:112)
[java] at org.apache.jorphan.test.AllTests.main(AllTests.java:236)
[java] 11) org.apache.jmeter.reporters.graphite.GraphiteListener - zh -
TW(org.apache.jmeter.testbeans.gui.PackageTest)java.util.MissingResourceException:
Can't find resource for bundle java.util.PropertyResourceBundle, key
graphiteHost.displayName
[java] at java.util.ResourceBundle.getObject(ResourceBundle.java:374)
[java] at java.util.ResourceBundle.getString(ResourceBundle.java:334)
[java] at
org.apache.jmeter.testbeans.gui.PackageTest.checkAllNecessaryKeysPresent(PackageTest.java:157)
[java] at
org.apache.jmeter.testbeans.gui.PackageTest.runTest(PackageTest.java:112)
[java] at org.apache.jorphan.test.AllTests.main(AllTests.java:236)
[java] There were 3 failures:
[java] 1)
testMaven(org.apache.jmeter.JMeterVersionTest)junit.framework.AssertionFailedError:
Should have no names left: [commons-pool2, commons-math3]. Check
ApacheJMeter_parent.pom
[java] at
org.apache.jmeter.JMeterVersionTest.testMaven(JMeterVersionTest.java:167)
[java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[java] at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[java] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[java] at org.apache.jorphan.test.AllTests.main(AllTests.java:236)
[java] 2)
runTestElement(org.apache.jmeter.junit.JMeterTest)junit.framework.AssertionFailedError:
SaveService nameMap (saveservice.properties) should contain
org.apache.jmeter.reporters.graphite.GraphiteListener
[java] at
org.apache.jmeter.junit.JMeterTest.checkElementAlias(JMeterTest.java:553)
[java] at
org.apache.jmeter.junit.JMeterTest.runTestElement(JMeterTest.java:540)
[java] at sun.reflect.GeneratedMethodAccessor39.invoke(Unknown Source)
[java] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[java] at org.apache.jorphan.test.AllTests.main(AllTests.java:236)
[java] 3)
runGUITitle(org.apache.jmeter.junit.JMeterTest)junit.framework.AssertionFailedError:
component_reference.xml needs 'Graphite_Listener' anchor for
org.apache.jmeter.testbeans.gui.TestBeanGUI
[java] at
org.apache.jmeter.junit.JMeterTest.runGUITitle(JMeterTest.java:368)
[java] at sun.reflect.GeneratedMethodAccessor29.invoke(Unknown Source)
[java] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[java] at org.apache.jorphan.test.AllTests.main(AllTests.java:236)
[java] FAILURES!!!
[java] Tests run: 2530, Failures: 3, Errors: 11
BUILD FAILED
/home/milamber/W-workspaces/Workspaces-JMeter/Jmeter/build.xml:2677: Java
returned: 1
Total time: 3 minutes 12 seconds
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 55932] Create a Async BackendListener to allow easy plug of new
listener (Graphite, JDBC, Console,...)
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55932
UbikLoadPack support <su...@ubikloadpack.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|Create a Graphite Listener |Create a Async
| |BackendListener to allow
| |easy plug of new listener
| |(Graphite, JDBC,
| |Console,...)
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 55932] Create a Async BackendListener to allow easy plug of new
listener (Graphite, JDBC, Console,...)
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55932
--- Comment #7 from UbikLoadPack support <su...@ubikloadpack.com> ---
See:
See:
http://mail-archives.apache.org/mod_mbox/jmeter-dev/201401.mbox/%3CCAH9fUpbt-_x1fFcYCTn9fVEqFL68E_N9YLkkhYs4RnpiRSx+Og@mail.gmail.com%3E
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 55932] Create a Async BackendListener to allow easy plug of new
listener (Graphite, JDBC, Console,...)
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55932
Philippe Mouawad <p....@ubik-ingenierie.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Blocks| |57246
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 55932] Create a Graphite Listener
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55932
--- Comment #5 from Philippe Mouawad <p....@ubik-ingenierie.com> ---
Hello Milamber,
Thanks for tests, there is no response time, just percentile95 and
percentile90.
Regarding tests failure, I was planning to fix this if we agree to commit
patch.
Is it ok for commiting it ?
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 55932] Create a Async BackendListener to allow easy plug of new
listener (Graphite, JDBC, Console,...)
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55932
Philippe Mouawad <p....@ubik-ingenierie.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #8 from Philippe Mouawad <p....@ubik-ingenierie.com> ---
Date: Sat Nov 22 15:36:37 2014
New Revision: 1641081
URL: http://svn.apache.org/r1641081
Log:
Bug 55932 - Create a Async BackendListener to allow easy plug of new listener
(Graphite, JDBC, Console,...)
Bugzilla Id: 55932
Added:
jmeter/trunk/src/components/org/apache/jmeter/visualizers/backend/
jmeter/trunk/src/components/org/apache/jmeter/visualizers/backend/AbstractBackendListenerClient.java
(with props)
jmeter/trunk/src/components/org/apache/jmeter/visualizers/backend/BackendListener.java
(with props)
jmeter/trunk/src/components/org/apache/jmeter/visualizers/backend/BackendListenerClient.java
(with props)
jmeter/trunk/src/components/org/apache/jmeter/visualizers/backend/BackendListenerContext.java
(with props)
jmeter/trunk/src/components/org/apache/jmeter/visualizers/backend/BackendListenerGui.java
(with props)
jmeter/trunk/src/components/org/apache/jmeter/visualizers/backend/SamplerMetric.java
(with props)
Modified:
jmeter/trunk/bin/saveservice.properties
jmeter/trunk/build.properties
jmeter/trunk/build.xml
jmeter/trunk/eclipse.classpath
jmeter/trunk/res/maven/ApacheJMeter_parent.pom
jmeter/trunk/src/core/org/apache/jmeter/resources/messages.properties
jmeter/trunk/src/core/org/apache/jmeter/resources/messages_fr.properties
jmeter/trunk/src/core/org/apache/jmeter/samplers/SampleResult.java
jmeter/trunk/src/core/org/apache/jmeter/save/SaveService.java
jmeter/trunk/xdocs/changes.xml
jmeter/trunk/xdocs/usermanual/component_reference.xml
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 55932] Create a Async BackendListener to allow easy plug of new
listener (Graphite, JDBC, Console,...)
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55932
Bug 55932 depends on bug 57321, which changed state.
Bug 57321 Summary: BackendListener reports partial results in master-slave configuration (nightly build r1642603)
https://issues.apache.org/bugzilla/show_bug.cgi?id=57321
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |FIXED
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 55932] Create a Async BackendListener to allow easy plug of new
listener (Graphite, JDBC, Console,...)
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55932
Milamber <mi...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|FIXED |---
--- Comment #11 from Milamber <mi...@apache.org> ---
When I run the ant distribution task, I have this error:
[java] There was 1 error:
[java] 1)
GUIComponents2(org.apache.jmeter.junit.JMeterTest)java.lang.NumberFormatException:
For input string: ""
[java] at
java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
[java] at java.lang.Integer.parseInt(Integer.java:470)
[java] at java.lang.Integer.parseInt(Integer.java:499)
[java] at
org.apache.jmeter.visualizers.backend.BackendListenerGui.modifyTestElement(BackendListenerGui.java:268)
[java] at
org.apache.jmeter.visualizers.backend.BackendListenerGui.createTestElement(BackendListenerGui.java:257)
[java] at
org.apache.jmeter.junit.JMeterTest.GUIComponents2(JMeterTest.java:445)
[java] at sun.reflect.GeneratedMethodAccessor27.invoke(Unknown Source)
[java] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[java] at org.apache.jorphan.test.AllTests.main(AllTests.java:236)
If the queueSize is empty, the NFE occurs.
Several solutions (in my mind):
1/ add a try catch block (and ignore the NFE or set a default value)
2/ use a if/then/else block (set a default value if null or emtpy)
and change the docs (not require, indicate the default value)
--
You are receiving this mail because:
You are the assignee for the bug.