On Thu, Feb 2, 2017 at 9:44 PM, Vladimir Sitnikov < sitnikov.vladi...@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.
