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.

Reply via email to