On 25 March 2014 23:02, Philippe Mouawad <[email protected]> wrote: > On Wednesday, March 26, 2014, sebb <[email protected]> wrote: > >> On 25 March 2014 22:31, Philippe Mouawad >> <[email protected]<javascript:;>> >> wrote: >> > They differ because in Test Action case, there is a sleep which is taken >> > as processing of Sampler. >> >> If you set the Test Action sleep to zero, it won't affect the TC output. >> >> But my aim was to control better pause time. > So ok it answers other needs but not my main one.
See below. >> > While with my strategy the timer being a child of DebugSampler it will >> act >> > as TestAction but as time is within a timer it will not affect time taken >> > by DebugSampler. >> > Make the test sebb you will see. >> >> I have, and I did not see a problem. >> >> Set it to > 0 and you will see the difference Well of course, but the suggestion from Shmuel was to use a dummy Test Action as the parent for the Timer. Simply replace the Debug Sampler with a Test Action Sampler that does nothing. >> > On Tue, Mar 25, 2014 at 11:26 PM, sebb <[email protected]> wrote: >> > >> >> On 25 March 2014 21:53, Philippe Mouawad <[email protected]> >> >> wrote: >> >> > On Tue, Mar 25, 2014 at 10:46 PM, Shmuel Krakower <[email protected] >> >> >wrote: >> >> > >> >> >> Regarding the timer just put it under A Test Action which is already >> >> hidden >> >> >> from results... >> >> >> >> >> > >> >> > No it is not the same, because I usually use a Transaction Controller >> >> and >> >> > have HTTP Sampler as its children . >> >> > Using Test Action will make Transaction Sampler report time taken by >> HTTP >> >> > Sampler + Test Action which I don't want. >> >> > While using Timer will give correct time. >> >> >> >> The Debug Sampler is a sampler, the same as the Test Action sampler. >> >> So I don't see how they differ when used under a TC. >> >> Note that the Test Action controller itself does not have to wait. >> >> >> >> >> >> >> >> www.beatsoo.org - free application performance monitoring from world >> >> wide >> >> >> locations. >> >> >> On Mar 25, 2014 11:38 PM, "Philippe Mouawad" < >> >> [email protected]> >> >> >> wrote: >> >> >> >> >> >> > On Tue, Mar 25, 2014 at 10:30 PM, sebb <[email protected]> wrote: >> >> >> > >> >> >> > > On 25 March 2014 21:27, Philippe Mouawad < >> >> [email protected]> >> >> >> > > wrote: >> >> >> > > > On Tue, Mar 25, 2014 at 5:05 PM, sebb <[email protected]> >> wrote: >> >> >> > > > >> >> >> > > >> On 25 March 2014 07:42, Shmuel Krakower <[email protected]> >> >> wrote: >> >> >> > > >> > Maybe we can go with simple approach of adding a boolean >> data >> >> >> member >> >> >> > > to >> >> >> > > >> the >> >> >> > > >> > sampler base class of Hidden and all listeners add a piece >> of >> >> code >> >> >> > to >> >> >> > > >> > ignore those who are marked hidden? >> >> >> > > >> >> >> >> > > >> The boolean would have to be added to the SampleEvent / >> >> SampleResult >> >> >> > > >> class, as Listeners only operate on them. >> >> >> > > >> >> >> >> > > >> It would be possible to check this flag before invoking the >> file >> >> >> > output >> >> >> > > >> section. >> >> >> > > >> >> >> >> > > >> However the sample would still be sent to all Listener GUIs, >> even >> >> >> ones >> >> >> > > >> that operate on "real" data, such as the Summariser. >> >> >> > > >> Yes, one could amend all of these as well to reject "debug" >> data, >> >> >> but >> >> >> > > >> what about all the 3rd party code? >> >> >> > > >> >> >> >> > > >> It has long been a fundamental design feature of JMeter that >> all >> >> >> > > >> results go to all Listeners in scope, and all results are sent >> >> >> equally >> >> >> > > >> to file and GUI. >> >> >> > > >> >> >> >> > > >> I think changing this strategy is extremely risky, and will >> >> likely >> >> >> > > >> cause more problems than the minor issue it is proposed to >> solve. >> >> >> > > >> >> >> >> > > > >> >> >> > > > I think there is a misunderstanding. >> >> >> > > > I > > > > -- > Cordialement. > Philippe Mouawad.
