When loading JMeter, the splash screen (at least under Windows) is system modal, meaning it's on top of everything running on the desktop. The splash screen is stays in the middle of the screen (no way to move it), on top of all other windows, thus partially hiding most applications windows. When loading a big test file, the splash screen stays on my (pretty recent and powerful laptop) sometimes up to 30 s. So I cannot work at all for 30 s, which is very frustrating. Why is the splash screen system modal and not application modal? The latter sounds the most logical to me and is aligned with good practices. Thanks
A normal startup time with splash screen should be around a second or two, not thirty seconds. Do you have any third party plugins installed? Are there any log/error messages in the log file jmeter.log? Would you be able to take a few threaddumps of the JVM while starting JMeter? To your last question: patches are welcome :)
As I said, the delay may increase a lot when you load a test at start-up (-t mytestfile.jmx). For the patch, although it's probably trivial (a constant to change in the method call), I unfortunately don't have the Java skills to do it :-(
Can you please answer the questions? I think the answers might be helpful (to help you). I don't think, that JMeter sets explicitly the splash screen to be system modal and my rudimentary search on google told me, that Java doesn't support a system modal dialog. Perhaps you are annoyed by the always on top dialog, which is a slightly different (but probably also annoying) thing.
Created attachment 37388 [details] Loaded plug-ins
You're right, it's an "always on top dialog" - bad wording. Starting JMete alone takes 15 s; adding a big jmx file can addd 15 or 30 s. I attached a screenshot of my plug-ins. Nothing in jmeter.log. Taking threaddumps is out of my expertise :-(
If you are using a current version of OpenJDK (or a commercially licensed Oracle JDK), you can enable the flight recorder and look into the state of the JVM afterwards. You could add the following line to your bin/setenv.bat (or bin/setenv.sh under linux) to enable the flight recorder and save the events in a file named recording.jfr JVM_ARGS="-XX:StartFlightRecording=disk=true,dumponexit=true,filename=recording.jfr,maxsize=1024m,maxage=1d,settings=profile,path-to-gc-roots=true" (Note I have tried this under linux, only) The recording can be analysed with the tool Mission Control (which can be downloaded from the AdoptOpenJDK and other places). If you are not afraid to send the recording data to me, I could take a look into it. Another trick you could try is to look at the network connections JMeter is trying to open on startup (it shouldn't open any on it's own, but the plugins might do so) with a windows system monitoring tool you like.
Hi Marc, to debug your problems hopefully a bit easier, I have added debug messages at the point in the startup sequence, that happens when the splash screen is displayed. To enable the debug logs, you have to add an entry to bin/log4j2.xml <Logger name="org.apache.jmeter.JMeter" level="debug" /> I placed it directly under the entry for name="org.apache.jmeter.junit". On the next start up, you should see the following lines in the jmeter.log file: 2020-08-10 17:59:06,697 DEBUG o.a.j.JMeter: Apply HiDPI on fonts 2020-08-10 17:59:06,697 DEBUG o.a.j.JMeter: Configure PluginManager 2020-08-10 17:59:06,698 INFO o.a.j.JMeter: Loaded icon properties from org/apache/jmeter/images/icon.properties 2020-08-10 17:59:06,720 DEBUG o.a.j.JMeter: Setup tree 2020-08-10 17:59:07,040 DEBUG o.a.j.JMeter: populate command map 2020-08-10 17:59:07,553 DEBUG o.a.j.JMeter: init instance 2020-08-10 17:59:07,553 DEBUG o.a.j.JMeter: constructing main frame commit 44c0c7ee1a18b86528adf07607839614166d60f6 AuthorDate: Mon Aug 10 17:59:56 2020 +0200 Log status on start up, when splash screen is displayed Be more verbose on the init phase, when the startup splash screen is being displayed. This can hopefully be used to pinpoint problems on startup more easily. Bugzilla Id: 64658 --- src/core/src/main/java/org/apache/jmeter/JMeter.java | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-)
Note: The logging will only work with the next nightly or builds from trunk. (See https://jmeter.apache.org/nightly.html)
Created attachment 37389 [details] Log This log corresponds to a display of the splash screen of about 33 s
Created attachment 37390 [details] Full log including jmx loading I enabled debug for everything. We see here that it's the loading of the jmx that takes most of the time (more than normal because we are in debug).
Felix, I'd love if you could speed-up the load of my project, obviously. Anyway, I think the splash screen shouldn't stay on top of other windows - that's very intrusive. Maybe an option?
Marc, 1) Splash screen disappears just when the application is ready. Making it disappear earlier won't enable you work with the application earlier 2) The log you provide does include java.lang.OutOfMemoryError: Java heap space So I would suggest either increase -Xmx or collect a heap dump and analyze it for the heap consumption 3) Could you share the jmx file so we can replicate the issue?
1) Splash screen disappears just when the application is ready. Making it disappear earlier won't enable you work with the application earlier No, but at least I would be able to work on other Windows ... 2) The log you provide does include java.lang.OutOfMemoryError: Java heap space So I would suggest either increase -Xmx or collect a heap dump and analyze it for the heap consumption That's just because the debug mode uses too much memeory for a big project 3) Could you share the jmx file so we can replicate the issue? If needed, but I have the same problem with all projects. Maybe I wasn't clear: If you have a big project, it takes a long time to load it. I understand and I accept that. The only problem is that I cannot work on my PC when it's loading the project. The point is not to optimize the project load time (even if I would be happy to gain a few seconds), but simply to not block my screen with an image forbidding me to work. I would like to choose which window is on top myself and I don't see why JMeter should take such an initiative.
Adding a command line parameter to disable the splash screen would probably be an option to solve one of your problems. But I think it would even be better to make the import faster. There are a lot of "clean cookies" messages from the debug log (thanks for providing it) and I wonder, if we "enable/reset" the added elements too often on load. Can you give us more information on your used test plan? It seems to be rather big and I would like to test it locally, to get a better understanding, where we should optimize the loading sequence.
A command line parameter to disable the splash screen would be perfect
Disable splash screen per CLI option: https://github.com/apache/jmeter/pull/610
Great, Thanks. As soon as a JAR will be available, I'll test it.
In my experiments with the big test plan (that Marc has sent me privately), it is a really bad idea to enable the undo feature. It seems to be enabled while loading and really hurts performance wise. The test plan is built with quite a lot of different thread groups that can be enabled to test different things. The thread groups themselves are build from loops, samplers (JSR223, Beanshell, HTTP), config elements, but are not too big themselves. There are a few global config elements like a dns cache manager with static host entries (build from variables). And last but not least it contains module fragments, that are referenced inside the thread groups.
I suppressed the "undo" and it makes indeed a huge difference! Thanks for spotting the problem.
Marc, I've merged https://github.com/apache/jmeter/pull/614 which makes the splash-screen JMeter-modal rather than system modal. So it should no longer block other apps even in the case JMeter takes long to launch. You could find the build here: https://ci-builds.apache.org/job/JMeter/job/JMeter-trunk/43/ (or you can build from source by downloading git tree and running ./gradlew runGui)
It's perfect, thanks
*** Bug 62179 has been marked as a duplicate of this bug. ***
This issue has been migrated to GitHub: https://github.com/apache/jmeter/issues/5382