I am a devops team member and not apart of the development team, so if I say something that doesn’t make sense, let me know and I will try to get a better answer from the development team.
I am trying to scan a project that has various .net projects (framework,standard,core, and mixed). A build without sonarqube enabled takes between 4 and 6 minutes, and when I add in the SonarQube tasks, the build step takes 21-24 minutes. This is for both a Release and Debug build. Using Visual studio 2017. Platform Any CPU. Tried with both x64 and x86 but that made no difference. I know scanning with SonarQube will add time to the build, but this is a larger increase than expected.
Any ideas on what the problem is or how to reduce the time to scan?
Can you clarify what version you’re on? Taint analysis rules are available starting from Developer Edition($), and those can take longer to run. Also, the current version of the analyzer is 7.13. Could you upgrade and see what, if any, difference that makes?
Thanks for the response. I think there might’ve been some performance improvements in the DE version since 7.8. Please do upgrade if you can & report back.
Updated to 7.13 (build 8313) and there is no difference in the scan length. It seems to have identified less issues, so i suppose that could lead to a smaller average time, but the build still took nearly 22 minutes.
Hi @trgabriel ! Given that you are using SQ LTS (6.7.5), you don’t have the injection rules (they’ve been added in SQ 7.2, in a separate plugin than the C# plugin), so the problem probably lies somewhere else.
Could you please provide the verbose logs for the build step and the scanner end step (docs here)?
Thanks, I looked at the logs and didn’t find anything suspicious. One suggestion is to modify the logging only at error level, and by doing this you will probably gain some minutes - all Roslyn analysis messages are warnings (this is out of our control) - hence the huge log files.
I would have to profile the analysis to see if there are certain rules that take up the time, but for that I would need the source code. Please try keeping the log level at error and see what the perf increase is.
I saw a decrease of roughly a 30-60 seconds but that is also a small enough difference that it could just be an outlier. The dev team has also let me know that they would not want to do this as a long term solution for this problem.
One idea would be to disable the rules that are based on Symbolic Execution and we know they are more costly. These rules are S1944,S2259,S2583,S2589,S3655,S3900,S3966,S4158.
Another way to gain more insight in which rules are eating up the time is to use the -reportAnalyzer MSBuild option, and then disable the greedy rules for your project…
msbuild /p:reportanalyzer=true /v:d
If you run the build with reportanalyzer, please share the results with us In the medium term, we want to gather more metrics on the performance of our rules, any help counts.
Disabling the rules described above resulted in a build time of 19:47. Roughly a 2 minute reduction. Will need to talk to the team if the rules disabled are worth the two minutes. Attempting to run the reportAnalyzer results now. Will send the results in a direct message if successful. I may need to push this back until Monday.
I tried adding both:
msbuildArgs: ‘-reportAnalyzer:True’
and
msbuildArgs: ‘-ReportAnalyzer:True’
to the VSBuild azure dev ops task, and neither worked. Do you know what I am doing wrong?
The results are part of the MSBuild output. Search the log output for the step for the text Total analyzer execution time:. There will be one set of results for each MSBuild project.
Total analyzer execution time: 893.913 seconds.
NOTE: Elapsed time may be less than analyzer execution time because analyzers can run concurrently.
Time (s) % Analyzer
893.913 100 SonarAnalyzer.CSharp, Version=7.13.0.0, Culture=neutral, PublicKeyToken=c5b62af9de6d7244
448.313 50 SonarAnalyzer.Rules.CSharp.TokenTypeAnalyzer
445.228 49 SonarAnalyzer.Rules.CSharp.SymbolReferenceAnalyzer
What rules do these correspond to? Also, who should I send the metrics of the rule performance to? I will just cut out all of the similar blocks of text as what I pasted above.
In the medium term, we want to gather more metrics on the performance of our rules, any help counts.