Am 30.12.2015 um 16:30 schrieb Philippe Mouawad:
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.
So this is only a problem of ProxyControl? Maybe we could use
invokeAndWait there and change the "real" listeners to invokeLater?
Felix
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.
