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 <[email protected]> wrote: > On 19 August 2013 08:51, Danny Lade <[email protected]> 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:[email protected]] > >> Gesendet: Sonntag, 18. August 2013 23:07 > >> An: [email protected] > >> Betreff: Re: About HoldSampleSender > >> > >> On 15 August 2013 22:02, Philippe Mouawad > >> <[email protected]> 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.
