We just updated our SonarQube Server Developer Edition from LTS Version 7.9.6 to 8.9.7 and unfortunately observed a huge increasement of analysis time in our java projects.
For example we have a project with approx 420k LoC (95% Java + a bit JavaScript).
Before the JavaSquidSensor took about 12 minutes to finish and now it takes about 150 minutes which is about more than 10 times as long.
We have not changed any SonarScanner parameters.
We are running SonarScanner for Linux:
18:01:47.012 INFO: SonarScanner 4.7.0.2747
18:01:47.015 INFO: Java 11.0.12 Eclipse Foundation (64-bit)
18:01:47.015 INFO: Linux 4.15.0-169-generic amd64
With 7.9:
INFO: Sensor JavaSquidSensor [java] (done) | time=728416ms
Between 7.9 and 8.9, we rewrote Java analysis for higher precision. That came with a performance trade-off, but I wouldn’t expect it to be this large.
Could you add -Dsonar.java.performance.measure=true to your next analysis and post the resulting file?
Thanks for providing this report.
It seems that parsing time is taking a large part of this time, which is unexpected.
There is a chance that the parser introduced in the latest version of the Java Analyzer (it was not the case with the one embedded in LTS 7.9.6) is struggling to build a semantic model taking into account all the libraries required by your project. We are currently working on a solution, but it is not yet in production.
Can you run your analysis in debug mode, and check the number of libraries which are provided for properties sonar.java.libraries and sonar.java.test.libraries? Usually maven or gradle scanners are configuring by default these properties correctly, but there is a chance that it might be wrongly configured.
If there is a large number of them (more than 100), can you check if they all make sense in the context of your project?
We are creating a fresh local maven repository from scratch on every build, so it should only contain artifacts consumed or created by this build. This local repository is then used for sonar.java.libraries property.
As this is a quite large project (about 420k LoC) this local repository contains more than 2400 individual jar files. To be honest I don’t know if the scope of these libraries can be restricted further. Last but not least because the supported wildcard syntax is quite a limiting factor here.
I also made a quick test by running sonarScanner maven plugin with self discovering the libraries, but that did not make any difference in performance.
You indicated, that you are aware of issues related to creating the semantic model. Can you reveal more details here? Is there a timeline when a solution can be expected? Maybe we can stay at Sonar 7.9 until there is a fix in sight.
We hope you understand that if there is no solution in sight here, it is very unlikely that we will renew the license next time. This experience is not what we expect from a commercial product.
While you’ve apparently purchased a commercial product, you didn’t opt for commercial support.
You’ve been dealing directly with the relevant developers here. While they’re naturally concerned about performance problems they have many other irons in the fire and are only able to give attention to community threads around their other priorities. If you need defined SLAs, our team of professional Support Engineers will be happy to provide that.
That said, we do anticipate a marked improvement in Java analysis performance in 9.4, which should be released in early April. And I believe investigations into your performance are still underway.
And by any chance, are you running any custom rules?
Looking at the performance results again, it seems that 5 rules are already taking up a large part of the analysis time (23 minutes). This is rather unexpected. To speed up things, you might want to try to disable them. The rules are:
java:S2653: Web applications should not have a “main” method
The rule is deprecated, it should not be part of your QP! anymore! It has been dropped from the more recent versions
java:S4818: Using Sockets is security-sensitive
The rule is also deprecated, it should not be part of your QP! anymore! It has also been dropped from the more recent versions
java:S2092: Creating cookies without the “secure” flag is security-sensitive
java:S2755: XML parsers should not be vulnerable to XXE attacks
java:S2095: Resources should be closed
We continuously improve rules and fine-tune their performances, but the latest versions of our analyzer are NOT available with the LTS version. To benefit from them, you would need to use SQ 9.X series, and update at each new release.
Also, disabling the rules beforementioned would only be a workaround. In your case, it seems that the PARSING itself takes already a ton of time. This is unfortunate. The number of dependencies involved is likely to cause a huge semantic model to be created for each file, killing the performance and slowing down radically the analysis.
For the time being, and I’m sad to say it, I would recommend, in your special case (for any others, moving to the latest LTS is the only recommended way), to stay on SQ 7.9.6.
Now, like @ganncamp mentioned earlier, we are actively working on providing better solutions for such massive projects. Starting from SonarQube 9.4 (the next SonarQube release), the java analyzer will be:
By default analyzing files by batch instead of one by one.
Our internal measures show significant improvements on all big projects
The default size of a batch will be fine-tunable manually if necessary (experimental)
For Pull-Request analysis, an incremental analysis mode will be introduced, which will only target changed files and speed up feedback on small changes submitted for review.
Both these changes should hopefully have massive impacts on your performance, but they will require you to move to the latest release of SonarQube. These changes will NOT be backported to LTS.