On Fri, Dec 7, 2012 at 7:51 PM, sebb <[email protected]> wrote:

> On 7 December 2012 18:34, Philippe Mouawad <[email protected]>
> wrote:
> > Starting with  1000 threads with sometime pages taking 200 Ko, that can
> > take much useless memory particularly for previous sample result which is
> > not used 90% of time.
>
> Isn't the previous sample result needed for Assertions and Post-Processors?
> Or is that done separately?
>
> You are right. Stupid idea of mine :-)


> > Shouldn't we give it a try ?
>
> My concern is that this could be a cause of subtle failures if used
> inappropriately, and could cause unnecessary support requests that
> take a long time to investigate and answer - i.e. we could be causing
> a lot of support work.
>
> > On Friday, December 7, 2012, sebb wrote:
> >
> >> On 7 December 2012 17:15, Philippe Mouawad <[email protected]
> <javascript:;>>
> >> wrote:
> >> > Hello,
> >> > What about implementing a kind of agressive mode for High Load Tests.
> >> >
> >> > It would be a Config Element that would change slightly JMeter
> behaviour:
> >> >
> >> >    - Nullify  previous SampleResult
> >> >    - Nullify JMeterContext#previousSampler
> >> >    - Clean response data as soon as sampling and post/processor ,
> >> >    assertions have been done
> >>
> >> I think that would stop the listeners from working.
> >>
> >> >
> >> > Other field of improvements would be to work on HashTree size and
> >> cloning.
> >> >
> >> > What are your thoughts ?
> >>
> >> Unless the test plan includes a listener that saves copies of every
> >> sample result, then at most two samples will be saved (current and
> >> previous) per thread.
> >>
> >> Is there really a problem with memory usage for high load tests -
> >> unless the samples are huge?
> >>
> >> The risk is that clearing the data will cause subtle test failures
> >> which are very hard to debug.
> >>
> >> > Regards
> >> > Philippe
> >>
> >
> >
> > --
> > Cordialement.
> > Philippe Mouawad.
>



-- 
Cordialement.
Philippe Mouawad.

Reply via email to