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