jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Philippe Mouawad <philippe.moua...@gmail.com>
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 <
sitnikov.vladimir@gmail.com> 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.
> https://drive.google.com/drive/folders/0B1uBdVuLED5NejZaanZ2UHNlblk )
> 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
>



-- 
Cordialement.
Philippe Mouawad.

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