Way to compute number of threads per Thread Group during a load Test

[Philippe Mouawad <ph...@gmail.com>]

Hello,
1/ I am trying to add to GraphiteBackenListenerClient the number of threads
per thread group but I am not sure what's the best way to compute it so
that it also works for distributed testing:
- Does this method look good to you : comulate
sampleResult.getGroupThreads() and every second return this number divided
by number of sampleResults used to compute it and as a consequence reset
number to 0 at every second ?

2/ I am also not satisfied with the way we compute All threads, as
currently UserMetric uses a DescriptiveStatistics but in fact nearly has
always the same value, so it's a bit useless.

3/ By the way in distributed mode, to work properly I think time_threshold
should be set to 1000.

Your help and thoughts is welcome on this .
Thanks

Regards
Philippe

Re: Way to compute number of threads per Thread Group during a load Test

[Philippe Mouawad <ph...@gmail.com>]

On Monday, March 2, 2015, sebb <se...@gmail.com> wrote:

> On 2 March 2015 at 15:42, Philippe Mouawad <philippe.mouawad@gmail.com
> <javascript:;>> wrote:
> > Hello,
> > 1/ I am trying to add to GraphiteBackenListenerClient the number of
> threads
> > per thread group but I am not sure what's the best way to compute it so
> > that it also works for distributed testing:
> > - Does this method look good to you : comulate
>
> What does comulate mean?
> compute?
>
>  Yes compute

> > sampleResult.getGroupThreads() and every second return this number
> divided
> > by number of sampleResults used to compute it and as a consequence reset
> > number to 0 at every second ?
>
> This does not sound like it would return the number of threads per thread
> group.
>
> But perhaps you meant to average the number across several samples.
>
> yes


> Why does the number have to be calculated every second?

because that's the frequence at which backend listener sends metrics to
backend

Are other statistics done the same way?

no

>
> > 2/ I am also not satisfied with the way we compute All threads, as
> > currently UserMetric uses a DescriptiveStatistics but in fact nearly has
> > always the same value, so it's a bit useless.
>
> Please use separate threads for separate issues

why? this thread is related to backend computation

>
> > 3/ By the way in distributed mode, to work properly I think
> time_threshold
> > should be set to 1000.
>
> Please use separate threads for separate issues
>
>  why? this thread is related to backend computation

> Your help and thoughts is welcome on this .
> > Thanks
> >
> > Regards
> > Philippe
>


-- 
Cordialement.
Philippe Mouawad.

Re: Way to compute number of threads per Thread Group during a load Test

[sebb <se...@gmail.com>]

On 2 March 2015 at 15:42, Philippe Mouawad <ph...@gmail.com> wrote:
> Hello,
> 1/ I am trying to add to GraphiteBackenListenerClient the number of threads
> per thread group but I am not sure what's the best way to compute it so
> that it also works for distributed testing:
> - Does this method look good to you : comulate

What does comulate mean?
compute?

> sampleResult.getGroupThreads() and every second return this number divided
> by number of sampleResults used to compute it and as a consequence reset
> number to 0 at every second ?

This does not sound like it would return the number of threads per thread group.

But perhaps you meant to average the number across several samples.

Why does the number have to be calculated every second?
Are other statistics done the same way?

> 2/ I am also not satisfied with the way we compute All threads, as
> currently UserMetric uses a DescriptiveStatistics but in fact nearly has
> always the same value, so it's a bit useless.

Please use separate threads for separate issues

> 3/ By the way in distributed mode, to work properly I think time_threshold
> should be set to 1000.

Please use separate threads for separate issues

> Your help and thoughts is welcome on this .
> Thanks
>
> Regards
> Philippe