Hi Felix, I remember now my issues. They occured during recording, I have just tested again your patch, and for example one of the issues: - Use Recording Template - Start Recording
your will see that samples do not go under TransactionController as they should for 1 click on a screen that triggers 2 calls. I get 1 sample under the previous TC and 1 under the new one. Sometimes all samples are under the previous one and the new TC is empty. Regards On Wed, Dec 30, 2015 at 2:40 PM, Philippe Mouawad < [email protected]> wrote: > > > On Wed, Dec 30, 2015 at 1:43 PM, Felix Schumacher < > [email protected]> wrote: > >> Am 30.12.2015 um 13:23 schrieb Philippe Mouawad: >> >>> Hi Felix, >>> I think I tried this change few months ago, i remember I faced bugs in >>> display. >>> I don't remember exactly what but maybe I' m mixing with another place. >>> It was in same jvm(no remote) >>> >> The numbers below where on a local X. The heavy lock contention would >> result in even worse numbers. >> > Ok > >> >> The only difference I saw was a slight delay after the test had finished, >> before all results where shown. On the other hand that delay could be >> noticed while running the test when invokeAndWait is used. >> > > Could you propose a patch , I will test it again. What Java version are > you using ? > > >> Note that we advise users not to use gui mode for load testing. >>> >> Right, but they will do it anyway. >> > Yes but it's under their responsability. Their results will be wrong, we > advised in a lot of places. > Even if we fix this part, using GUI will introduce contentions and side > effects. > >> >> Felix >> >> >>> Regards >>> >>> On Wednesday, December 30, 2015, Felix Schumacher < >>> [email protected]> wrote: >>> >>> Hi all, >>>> >>>> with bug 52694 and commit 1245602 the new method JMeterUtils#runSafe was >>>> introduced, which uses SwingUtilities#invokeAndWait. >>>> >>>> I stumbled upon this while testing with gui and a report listener over >>>> remote X, where the invokeAndWait lead to heavy lock contention. >>>> >>>> A simple test with 1000 threads and 500 loops using a simple java >>>> sampler >>>> (0ms wait) and a Summary Report gives me >>>> >>>> invokeLater: ~100.000 req/s >>>> invokeAndWait: ~30.000 req/s >>>> >>>> In my naive implementation I ignored the potential exceptions, that >>>> invokeAndWait could throw, which we would have to catch using >>>> invokeLater >>>> in other ways, but since invokeLater is used already in other places, >>>> that >>>> should be no real problem. >>>> >>>> Any reason to use this instead of SwingUtilities#invokeLater? >>>> >>>> Regards, >>>> Felix >>>> >>>> >>>> >> > > > -- > Cordialement. > Philippe Mouawad. > > > -- Cordialement. Philippe Mouawad.
