V7.7.0 -> v8.4.2 upgrade doubled MS Build time

SonarQube Server / Community Build
,
1

We are currently using v8.4.2 of SonarQube analysis, we recently upgraded from v7.7.0.
Our project is a mainly C# project, with a small percentage of C++ sprinkled in. It’s a WPF project.
We have SonarQube integrated in our Azure build pipeline - and in it’s most basic sense, it’s set up like this:
image

Before the upgrade, the build step used to take around 7 minutes, and after the upgrade it now takes around 16 minutes - this is not good!

I had a look at the build logs, and the only differences I could find are the following:

  1. The /analyzers tag has two extra listed analyzers, SonarAnalyzer.CFG.dll, and Microsoft.AspNetCore.Razor.Language.dll - I have no idea how to turn these off, as these could be part of the cause for the extra time to build.
    image
    image2125×227 44.8 KB

    Some of the SonarQube issues detected therefore appear to be slightly different in the log too - but nothing too drastic.
  2. In the log for the ‘Run SonarQube Analysis’ step, there are some new steps that get executed for each project:
    INFO: 'sonar.coverage.jacoco.xmlReportPaths' is not defined. Using default locations: target/site/jacoco/jacoco.xml,target/site/jacoco-it/jacoco.xml,build/reports/jacoco/test/jacocoTestReport.xml INFO: No report imported, no coverage information will be imported by JaCoCo XML Report Importer INFO: Sensor JaCoCo XML Report Importer [jacoco] (done) | time=5ms INFO: Sensor ThymeLeaf template sensor [securityjavafrontend] INFO: Sensor ThymeLeaf template sensor [securityjavafrontend] (done) | time=0ms

However the ‘Run SonarQube Analysis’ step isn’t the part which is taking drastically longer.

I am wondering if:
A) anyone has any idea why the upgrade may have increased the build time
B) If the extra analyzers in #1 could affect this, and how to disable them.
C) Any other general pointers!

I’m a newb when it comes to SonarQube, so I can provide more information on request.
Thanks!

Update:
On the SonarQube website itself, on the same day that the upgrade happened, a lot of the quality gate rules appear to have changed too - this is the default SonarWay profile - so we have not touched this, it was only touched by the update. Below are the steps that have changed:

image
image1345×492 29.4 KB

image
image1496×1029 27.6 KB

I’m not really sure how to interpret this information, or find out what performance effect it has - i don’t really know why it’s been updated - I assume this is just part of upgrading the SonarQube.

2

hi @Red_Blob. Sorry for the delay.

I’ve answered here a similar problem. Between 7.9 and 8.4.2 we improved our security offering (detection of injection vulnerabilities) and this may be tied to this.

Could you please share the logs with reportanalyzer set to true? I’m mainly interested in the time taken by our rules.

  • msbuild /p:reportanalyzer=true /v:d > build.log

To get the most consuming rules for each project:

select-string -path “build.log” -pattern “NOTE: Elapsed time may be less than analyzer execution time because analyzers can run concurrently.” -Context 1,30 > analyzer_times.txt

And you can share the analyzer_times.txt file.

3

Hi!

I actually saw that post a while ago, so I’ve since run the logs and located the issue and got it back down to a decent running time. Sadly I lost the logs so cannot post them here yet, but I do have information on the rules which were causing us issues. We disabled these two rules and it reduced the build time back to semi-normal:

image
image1233×111 5.43 KB

The rules S4487 + S1144 (they both use the SonarAnalyzer.Rules.CSharp.UnusedPrivateMember) takes about 8 minutes of execution time.

The second longest rule is: SonarAnalyzer.Rules.CSharp.CbdeHandlerRule - this may save 1minute+ . The rule number and title for this I believe is - S3949: Calculations should not overflow.

1 Like
4

Thanks for the reply and feedback, @Red_Blob.

We’ve actually fixed the performance for S4487 + S1144 in #2474, and that’s included in SonarQube 8.5.

Note taken for S3949.

If you want to help us understand what rules we should target for perf improvements, you can still share the logs when you have time.

Thanks!
Andrei