Sonar Gradle Plugin taking 1hr+ to scan single JUnit XML file (200k tests, 36MB)

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.

  • Versions:
    Server: Sonarqube 9.9 LTS
    Sonar Gradle Plugin:
    Gradle: 8.6
    Java: Temurin-17.0.9+9

  • SonarQube deployment: via Helm

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

Relevant output:

[2024-02-05T15:45:19.640Z] Sensor SurefireSensor [java]
[2024-02-05T15:45:19.640Z] parsing [<path>/accelerators/module/math/build/test-results/test]
[2024-02-05T17:04:59.533Z] Sensor SurefireSensor [java] (done) | time=4768812ms

4768812ms = ~ 79.5 mins

Any ideas / suggestions?


Hi Brett,

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.


Hi G Ann Campbell,

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.

Thanks for the response!


Hi Brett,

No idea, but the code is open source… :smile:

I’m glad dropping the report was an option for you.