jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felix Schumacher <>
Subject Re: GUI Mode : OOM Protection for View Results Tree or View Results in Table
Date Fri, 03 Feb 2017 13:39:37 GMT
Am 03.02.2017 08:21, schrieb Felix Schumacher:
> Am 2. Februar 2017 21:44:43 MEZ schrieb Vladimir Sitnikov
> <>:
>>> Can you clarify your question if it's a real one.
>> Well, that's a real question.
>> It is a long time since I launched a load test, and I can't remember 
>> if
>> faced "UI stuck" error ever.
>> I would admit I've never used non-GUI mode, and GUI was just fine for
>> me
>> (of course I had to disable things like "view results").
>> Philippe>Did you see the last thread "High CPU utilization in
>> JMeter 3.x with HttpClient 4 leads to freeze" ?
>> I think I missed that.
>> A quick glance (e.g.
>> )
>> shows
>> that we have a logging problem.
>> That is  org.apache.jmeter.gui.LoggerPanel.processEvent might fill UI
>> event
>> queue, thus rendering UI unresponsive.
>> We might want to have some throttling there, or circular buffering, or
>> lazy-loading (e.g. logging to a file and refreshing it to the UI from
>> time
>> to time).
>> In any way, the number of threads itself has nothing to do with UI
>> responsiveness provided there is enough Xmx (remember we did discuss
>> "please specify new Xmx value and click restart" dialog?) and there is
>> enough CPU power (in case of CPU starvation the load test makes no
>> sense at
>> all).
>> Philippe>blocks Load test mode
>> You are right. It is much better to have application level error that
>> explains what goes wrong rather than fail with some obscure error at
>> runtime.
>> However I would like to explore if we can have a way out without
>> stopping
>> the show.
>> When captain opens the thread dump above, he would find some obvious
>> things:
>> 1) Logging fills the UI queue. The simplest workaround would be to
>> disable
>> log panel updates after N messages.
>> 2) Statistics posts UI events as well (SummaryReport.add). Can we have
>> some
>> debounce there, so the UI gets refreshed once a second at most?
>> Well, the above do not look like a quick win, however I think those 
>> can
>> be
>> fixed without complicating the codebase too much.
>> Does it make sense to spawn a couple of new mail threads regarding
>> those
>> issues?
> I think those are valid things to try out.

I tried it out and the resuls are promising.

Usage (%) in AWT Dispatcher
old code: 88
new (100ms): 44
new (500ms): 14

Usage (%) in Thread (mostly the JSR223-Sampler)
old code: 11
new (100ms): 55
new (500ms): 84

The test case I used was one Thread Group with 100 Threads and a single 
JSR223-Sampler with ""Blubb");"

Memory Usage (speak GC) went down to.


> Felix
>> Vladimir

View raw message