jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Philippe Mouawad <>
Subject Re: GUI Mode : OOM Protection for View Results Tree or View Results in Table
Date Thu, 02 Feb 2017 21:49:17 GMT
On Thu, Feb 2, 2017 at 9:44 PM, Vladimir Sitnikov <> wrote:

> >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").

Are you sure that for example using Summary report won't lead to freezes ?
I wouldn't bet it.

> 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).

For me there is jmeter.loggerpanel.maxlength which does not allow settings
more than 80k chars no ?

> 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).

That's definitely the issue Vladimir.
Many newbies or not aware of that.

> 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.

I'm proposing to not start it :-)

> 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.
See above but I think calling setText with big text has horrid performances
as per the JDK bug opened recently.

> 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?
Why not

> 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'd prefer a couple of PR :-)

> Vladimir

Philippe Mouawad.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message