Hi,
We’re getting extremely long scan times on a large Gradle project - however the vast majority of time appears to be around the ingestion of a very large JUnit file with 200k+ tests for a single module. JUnit XML output is ~ 36 MB in size.
what are you trying to achieve
A reasonable scan time for the project, the other modules are fine but this one is excessive, both in terms of the shear number of tests (200k+) and the size of the resulting JUnit XML output (~ 36MB)
what have you tried so far to achieve this
Running the analysis via Gradle ./gradlew sonar -Dsonar.verbose=true -Dsonar.log.level=INFO --info
During the run my machine had one CPU core pegged at 100% but the rest were fine (16 virtual cores).
For handling that JUnit file, I think it is what it is. It may help to make sure analysis has plenty of memory.
Beyond that, it depends on your priorities. If you value having analysis results quickly, then is it an option to drop the JUnit report from analysis? If not, it may be that you want to have two ‘versions’ of the project under analysis, one without JUnit that runs in the normal CI and one that’s analyzed over night and includes JUnit.
Out of curiosity, do you know if the scanner is using the Streaming version of the XML processor?
Given the specific nature of this module and the fact that it really is unit property testing that’s going on, we dropped the JUnit output from the analysis and the whole thing went from 1hr 20 mins to just under 2 mins.
We gave it -Xmx8g but I didn’t try increasing the metaspace as well. I’ll try it just for curiosity but otherwise we’re okay with dropping that particular analysis.
