jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Philippe Mouawad <philippe.moua...@gmail.com>
Subject Re: About HoldSampleSender
Date Mon, 19 Aug 2013 09:45:20 GMT
Stripping based SampleSender have now rather very good performances, I
think it is easier to use it then use independant non-GUI runs.
I think StrippedAsync should have nearly 0 impact on sampling .
But I agree creating one based on statistical data mining is interesting
option.

Regards
Philippe M.


On Mon, Aug 19, 2013 at 10:34 AM, sebb <sebbaz@gmail.com> wrote:

> On 19 August 2013 08:51, Danny Lade <D.Lade@bigpoint.net> wrote:
> > Before we have written our own SampleSender we tried this one.
> >
> > What makes it most worse is the fact that it stores the whole response
> body. Therefore rather small tests runs into OutOfMemory if the bodies are
> big (JSON/HTML).
> > Additionally it blocks the whole process because the sample store is
> (unnecessarily) synchronized.
>
> There is one class instance per Listener (in test plan or created by
> using -l flag).
> This is shared between threads, and testEnded uses a different thread,
> so access to the store must be synchronised.
> Both to ensure the the store is updated safely and to ensure safe
> publication.
>
> > In my opinion the only useful way to use a HoldSampleSender is one based
> on statistical data mining.
>
> Good point; it could be useful to create a new version for that, as it
> would avoid any network traffic during the run.
> However one could just use independent non-GUI runs instead...
>
> > IMHO Danny
> >
> >> -----Urspr√ľngliche Nachricht-----
> >> Von: sebb [mailto:sebbaz@gmail.com]
> >> Gesendet: Sonntag, 18. August 2013 23:07
> >> An: dev@jmeter.apache.org
> >> Betreff: Re: About HoldSampleSender
> >>
> >> On 15 August 2013 22:02, Philippe Mouawad
> >> <philippe.mouawad@gmail.com> wrote:
> >> > Hello,
> >> > Looking at this implementation, I wonder if it is really needed and
> >> > wether it should not be deprecated.
> >> >
> >> > It seems to me dangerous:
> >> >
> >> >    - It requires a lot of memory, users should be aware of it.
> >> >    - Even with lot of memory, it could impact highly performances of
> >> >    jmeter-servers through GC impacts
> >> >
> >> >
> >> > Thoughts ?
> >>
> >> Yes, it's probably not very useful, but we should probably not delete
> it (yet).
> >>
> >> Let's add some docs to say don't use it (and perhaps add a log.warn
> >> message on startup).
> >>
> >>
> >> > --
> >> > Regards.
> >> > Philippe M.
>



-- 
Cordialement.
Philippe Mouawad.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message