CODEWITHSUNDEEP
antjenkinssonarqubeanalysisfindbugs
Sreeram K
Sreeram K

Reputation: 93

SonarQube Analysis takes too much time

Even though it seems to point to the enormous number of lines of code (500,000), engineering is unconvinced why it takes 90 mins on a beefy Solaris box with 16GB RAM and dual-CPU to finish one Sonar analysis. Please tell me if 90 mins is too much time for a codebase this size.

I am checking out code from Git using Jenkins git plugin, running a full ant build which takes 45 mins and then running 'ant sonar' which populates data to a SonarQube server running 4.1.2 and which has a 'Quality profile' as the default profile consisting of findbugs, checkstyle and PMD. Total time is 45 + 90 mins.

When i use the incremental option, the analysis time goes down and it does "see" that only one file has to be analysed. However, as per the documentation, the diff analysis is not populated in the database, hence rendering that option useless for my purposes.

How can I reduce the time taken for each SonarQube analysis?

Upvotes: 9

Views: 18309

Answers (3)

Lonzak
Lonzak

Reputation: 9816

You basically need to identify your bottleneck. We don't know your (exact) hardware, your environment nor your configuration - so it is difficult to give advice.

  1. In our case (our project has lots of small files) we determined that the server IO was the first limiting factor - thus we exchanged our old fashioned magnetic drive with an SSD (in a different setting an SAS disk also helped a lot) and the sonar analysis speed up enormously.

  2. The next limitation was the CPU (GWT browser permutations compiling) and we replaces our 2 core cpu with an 8 core cpu...

  3. As a third thing we optimized our configuration and the settings (set localWorkers etc.) For sonar we checked all Findbugs, PMD rules which took some time but was worth it.

So as Fabrice suggested you need to check whats the limiting factor in your setup - network would could be one thing...

Now you may ask how to detect the bottleneck - that depends. For instance IO we checked like this:

  • Analysis of the CPU load history during build/sonar (CPUs not busy)
  • We created a tempory RAM drive (several GB) and let the build and sonar analysis run in there which proved that IO was a big factor. Furthermore in that setting the CPU was suddenly under full load...

Upvotes: 6

delloPiro
delloPiro

Reputation: 309

The two main factors I have found is the amount of rules you have enabled for the profile you test against and the type of plugins enabled. I can think of two ways to troubleshoot the root cause of the bottleneck.

  1. Run the analysis with a significantly reduced number of rules and see how long it takes then gradually increase the rules if you notice a drastic difference in time taken.

  2. Disable all the plugins enabled leaving only the essential ones and see if you save any time then gradually add plugins one at a time to see how much more time each enabled plugin adds to the analysis time.

Finally, I use TeamCity and when my analysis creeped into 3 hours, i went to the logs to see what program or plugin was taking time and this helped me narrow down which one to disable. I cut down analysis from 3 hours to 25 minutes following these steps.

Upvotes: 1

Fabrice - SonarSource Team
Fabrice - SonarSource Team

Reputation: 26843

If your build already takes 45 minutes, then I'm not surprised that the SonarQube analysis takes a lot of time as well. 500k LOC is a lot for a single project.

Here are some various ways to reduce the time:

  • First make sure that you run SonarQube server on a real DB, not on H2
  • Then, the analysis should occur very close to the SonarQube DB
    • If possible on the same machine
    • If not possible, analysis and DB should be located on the same high-bandwidth & high-speed LAN
  • Also, make sure that you activate only relevant rules, and not all the available rules (some are even redundant)

Upvotes: 6

Related Questions