How to speed up sonar scanner?

[mkapus...@kayak.com]

Hi,

how to cut scanner time (JAVA + Javascript + CSS + Properties + Groovy) from 6 hours to acceptable time?

Increasing the number of CPU cores didn't do much.

Splitting into modules does help just a little bit, since total time for all submodules takes ~6 hours as well.

Any advice is welcome :)

[G. Ann Campbell]

Hi,

In large part, the duration of scanning is directly related to the volume of code. If you have any generated files in your project, I would start by excluding them from analysis.

The next thing you might look at is making sure cross-project duplication detection is turned off. If you look closely at your analysis logs, you'll probably find that a lot of time is spent in duplication detection. 

And finally, I might consider breaking the sub-modules off into separate projects for analysis purposes. Doing this would allow you to scan different parts of the project independently. From a scheduling-of-analysis point of view, it would allow you to 

1. run scans in parallel, reducing overall clock time for analysis

2. skip re-scanning projects that hadn't changed that day

Doing it has two big caveats though:

1. You loose history on those sub-modules-cum-projects. And in fact, your migration path will probably have to start with deleting the aggregated project, then scanning the new sub-projects.

2. You would loose the ability to get an overall picture of the entire project in one place - unless you purchased the commercial Views plugin.

Hope this helps!

Ann

[Günter Wirth]

Hi,

I have also a performance issue with all my projects. What is the scanner doing at the end of each analysis? Is there a hint how to speed up this?

...
16:11:14.860 INFO  - Compare to previous analysis (2016-04-16)
16:11:14.876 INFO  - Compare over 14 days (2016-04-03, analysis of Sun Apr 03 22:58:44 CEST 2016)
16:11:14.876 INFO  - Compare over 90 days (2016-01-18, analysis of Mon Jan 18 18:43:58 CET 2016)
16:11:14.876 INFO  - FS
16:11:15.266 INFO  - Execute decorators...
16:11:22.130 INFO  - Store results in database
16:11:44.142 INFO  - Analysis reports generated in 608ms, dir size=1 MB
16:11:44.579 INFO  - Analysis reports compressed in 437ms, zip size=678 KB
16:11:45.624 INFO  - Analysis reports sent to server in 1045ms
16:11:45.624 INFO  - ANALYSIS SUCCESSFUL, you can browse http://yyyy.com:9000/dashboard/index/XXX
16:11:45.624 INFO  - Note that you will be able to access the updated dashboard once the server has processed the submitted analysis report.
INFO: ------------------------------------------------------------------------
INFO: EXECUTION SUCCESS
INFO: ------------------------------------------------------------------------
Total time: 2:07.190s
Final Memory: 20M/991M
INFO: ------------------------------------------------------------------------

Regards,
Günter

[G. Ann Campbell]

Hi Günter,

What version of the server are you on?

As to your question: it's doing what it says - storing the results in the database. The time that takes can be impacted by network speeds, and database load, as well as project size.

Ann

---

G. Ann CAMPBELL | SonarSource

Product Owner

http://sonarsource.com

--
You received this message because you are subscribed to a topic in the Google Groups "SonarQube" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sonarqube/CBkjuCpJyqA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to sonarqube+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/9e234228-66d8-47e5-8f09-2c0412729d4d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Modestas Kapusinskas]

Hi Ann,

Thanks for the quick reply!

—Bigproject

—————-\module1

Regarding running scans in parallel. I’ve encountered an issue, when launching analysis of sub-module (module1)  breaks the analysis of whole Bigproject which were running in background.

What is the best practice to run builds in parallel to avoid such issues?

 

KAYAK
Modestas Kapusinskas
Director Engineering

[G. Ann Campbell]

Uhm... the idea was to scan module1, module2, module3, ... instead of Bigproject. Not in addition to. 

---

G. Ann CAMPBELL | SonarSource

Product Owner

http://sonarsource.com

[Modestas Kapusinskas]

I understand the idea :)

I’m running whole project vs sub modules to see which one might be a better choice to use. So far we are willing to keep both builds 

Also, the scan of Bigproject takes roughly same amount of time as scan of all module1, module2, module3 …

KAYAK
Modestas Kapusinskas
Director Engineering

[G. Ann Campbell]

On Tue, Apr 19, 2016 at 11:01 AM, Modestas Kapusinskas <mkapus...@kayak.com> wrote:

I understand the idea :)

I’m running whole project vs sub modules to see which one might be a better choice to use. So far we are willing to keep both builds 

If you're analyzing them against the same SonarQube instance, that explains your errors. Those submodule keys can either be registered as part of a larger project or treated as projects on their own.

 

Also, the scan of Bigproject takes roughly same amount of time as scan of all module1, module2, module3 …

Yes, it would. 

[Günter Wirth]

Hello Ann,

We are using SQ 5.1.2 and sonar-runner-2.4.

Regards,
Günter

[G. Ann Campbell]

Okay. The scan stopped updating the database directly in 5.2, so the long step that says "store results in database" is doing just that.

Once you move past 5.1, you should see the client-side scan complete more quickly, but you'll have to wait for the analysis report to be processed server-side.

---

G. Ann CAMPBELL | SonarSource

Product Owner

http://sonarsource.com

To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/7c409518-d265-4a54-a0f4-a94ecde71ab5%40googlegroups.com.

[Günter Wirth]

Hi Ann,

Thanks I will try with SQ 5.2+. If analysis is on server-side: is the server able to handle several request from sonar-scanner in parallel or are they serialized?

Regards,
Günter

[G. Ann Campbell]

Serial in 5.2. By default, 5.5 (currently RC) uses 1 thread but can be configured to use more.

---

G. Ann CAMPBELL | SonarSource

Product Owner

http://sonarsource.com

To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/55244ca0-a458-4c65-9e1c-e934355f433e%40googlegroups.com.

[David]

Hi, 

Is there a way to see clearly where the time is being spent?

We have some large systems that are extremely slow to analyse and it has become slower over the years with subsequent SonarQube versions even though the code has hardly changed and our infrastructure has constantly been upgraded to newer / faster machines.

On one project back with Sonar 4.2 analysis took 20mins, now it is more than 2 hours.  

Another that previously took 2 hours takes now 6-8 hours. (207,000 lines of code)

Frustrating when only one or two lines have changed and a real killer to broader adoption within organisations. Analysing sequential check ins is really impossible for these.

In both examples, it is clear that the issue is within the JavaScript scanning engine and we see when run from the command line that the output stops for about 3 hours before picking up again with the latter project. This was confirmed with the msbuild runner which completes it's work within 20 mins on (the majority) C# code then hands over to sonar for JavaScript after which progress slows to a crawl.  Is there a way to figure out what rule(s)/components are causing the speed problem through additional timing output?

Being able to run incremental on the server would be a big help, (perhaps by marking the results with a clear 'Interim' badge) such that we would update with a full scan overnight. 

We run sonar 5.4, runner 2.6, msbuild runner 2.0 and do not have cross project duplication enabled, exclude 3rd party code (e.g. angular) and auto-generated code and are aware of sonarlint. Like most large established organisations we lag migration to new .NET versions and IDE's e.g. VS2015 for up to 2-3 years and so systems are currently on VS2012 because migration takes time with extensive re testing, including regulatory, required.  [Therefore retirement of the legacy VS runner too early would be a major setback].

We have tested these using MSBuild 2.0 targeting 14.0 (VS2015) but it makes no improvement in code analysis time.

Splitting projects is not an option and analysing sequential checkins is really impossible when analysis is so slow... (sigh)

With thanks,

David

[Pierre-Yves Nicolas]

Hi David,

As a maintainer of the JavaScript plugin, I'm really interested by your feedback.

What do you mean by "the output stops for about 3 hours before picking up again"?

The plugin should output a line about its progress every 10 seconds, for example:

03:50:29.340 INFO  - 15/6264 files analyzed, current file: /home/travis/build/SonarSource/sonar-javascript/its/sources/src/dojo-1.8.1/dijit/Menu.js.uncompressed.js

03:50:39.341 INFO  - 174/6264 files analyzed, current file: /home/travis/build/SonarSource/sonar-javascript/its/sources/src/dojo-1.8.1/dijit/dijit-all.js.uncompressed.js

03:50:49.341 INFO  - 369/6264 files analyzed, current file: /home/travis/build/SonarSource/sonar-javascript/its/sources/src/dojo-1.8.1/dijit/nls/dijit-all_it-it.js.uncompressed.js

Is this output blocked during 3 hours?

Pierre-Yves

--
You received this message because you are subscribed to the Google Groups "SonarQube" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sonarqube+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/cd80458f-8032-4678-ad66-5a3d151e2d2b%40googlegroups.com.

[David]

Hi Pierre,

I have come across a detailed log (418,000 lines, 120MB) made by a developer in March and spent some time working through it.  It looks like over 6 hours is lost in the middle.  This is what I see:

7 minutes into the analysis this happens:

13:28:07.113 DEBUG - Scanning MyProject:Dev:Invoice/js/spec/InvoiceSpec.js

13:28:07.126 DEBUG - Scanning MyProject:Dev:Invoice/js/spec/ItemCodeSearchSpec.js

13:28:07.141 DEBUG - Scanning MyProject:Dev:Invoice/js/spec/NewInvoiceLineSpec.js

13:28:07.145 DEBUG - Scanning MyProject:Dev:Invoice/js/spec/invoicelinesSpec.js

19:43:02.965 DEBUG - Scanning MyProject:Dev:Invoice/template/CCSD.html

19:43:03.002 DEBUG - Scanning MyProject:Dev:Medex/Assessment/html/Assessment.html

19:43:03.219 DEBUG - Scanning MyProject:Dev:Medex/Assessment/html/ClaimAssessment.html

19:43:03.284 DEBUG - Scanning MyProject:Dev:Medex/Assessment/html/ClaimEventLog.html

19:43:03.349 DEBUG - Scanning MyProject:Dev:Medex/Assessment/html/TreatmentEventLog.html

19:43:03.434 DEBUG - Scanning MyProject:Dev:Medex/Assessment/js/AssesmentEventLog.js

19:43:03.511 DEBUG - Scanning MyProject:Dev:Medex/Assessment/js/Assessment.js

Pulling up invoicelinesspec.js it is 85 lines long but contains some extreme http.when().respond() statements which look to be autogenerated (I hope).

There are a couple that exceed 42,000 characters (4,600 [human] words). 

Statements are like:

http.when("GET", "/api/LookUp?keyName=invoice_line_svce_code").respond(200, [{ "Value": "001", "Text": "Accommodation", "Key": "invoice_line_svce_code", "Filter": "3", "Flag": "N", "Id": "0", "CheckboxValue": null, "ShortName": null, "ReasonableCost": "450", "IsFSCPossible": null, "IsAccommodation": "Y" }, { "Value": "002", "Text": "Theatre Fee", "Key": "invoice_line_svce_code", "Filter": "11", "Flag": "N", "Id": "1", "CheckboxValue": null, "ShortName": null, "ReasonableCost": null, "IsFSCPossible": null, "IsAccommodation": "N" },.....

with many hundred of additional Value clauses in each statement running on for pages!

[The root cause of all these slowdowns may perhaps be long lines or depth of nest. Perhaps some bugout limits are needed (and a filter shown in SQ for files not analysed).]

and another later slow patch:

19:56:18.822 INFO  - Inspecting <Presentation>\<XXX.YYY.Web>\Content\Toaster\toaster.css

19:56:18.991 INFO  - Inspecting <Presentation>\<XXX.YYY.Web>\Content\IE\IE_only.css

19:56:19.098 INFO  - Inspecting <Presentation>\<XXX.YYY.Web>\Content\jasmine\jasmine.css

19:56:19.207 INFO  - Inspecting <Presentation>\<XXX.YYY.Web>\Content\ClaimsCommon.css

19:58:17.538 INFO  - Inspecting <Presentation>\<XXX.YYY.Web>\Content\Common.css

20:00:33.585 INFO  - Inspecting <Presentation>\<XXX.YYY.Web>\Content\ILPage.css

20:02:47.409 INFO  - Inspecting <Presentation>\<XXX.YYY.Web>\Content\InvoiceCommonModule.css

20:04:56.562 INFO  - Inspecting <Presentation>\<XXX.YYY.Web>\Content\NonMedexClaimModule.css

20:06:58.682 INFO  - Inspecting <Presentation>\<XXX.YYY.Web>\Content\bootstrap-responsive.css

20:06:59.845 INFO  - Inspecting <Presentation>\<XXX.YYY.Web>\Content\bootstrap.css

20:07:20.684 INFO  - Inspecting <Presentation>\<XXX.YYY.Web>\Content\claims-module.css

20:07:21.008 INFO  - Inspecting <Presentation>\<XXX.YYY.Web>\Content\flat-ui.css

and again 8 minutes goes by in script.js:

20:16:19.413 INFO  - Inspecting <Presentation>\<XXX.YYY.Web>\Search\Template\ProviderTemplate.html

20:16:19.568 INFO  - Inspecting <Presentation>\<XXX.YYY.Web>\Search\script.js

20:22:05.114 INFO  - Inspecting <Presentation>\<XXX.YYY.Web>\Search\search.js

20:22:17.981 INFO  - Inspecting <Presentation>\<XXX.YYY.Web>\Search\pageguide.html

Complete analysis finishes after 8 hours at 21:26 which would bring it in under the original 2 hours without that strange 6 hour break.

Does a break like this indicate a problem with particular file(s) or some other cause?

We will exclude invoicelinesspec.js for now and see what happens overnight. 

Finally, our analysis servers have a lot of idle processors / cores but all analysis seems to run under a single thread. Are there plans afoot to use / (customise the use of) available resources e.g, by language / component?

Best regards,

David

[Pierre-Yves Nicolas]

Hi David,

Thanks for the analysis.

Could you please check in your logs which sensor is active when things get slow?

That should be logged for all sensors.

For example, for JavaScript, you should see something like:

15:10:14.996 INFO  - Sensor JavaScriptSquidSensor

[many lines...]

15:10:16.144 INFO  - Sensor JavaScriptSquidSensor (done) | time=1148ms

About parallelising an analysis, we didn't go in this direction so far.

If you have a lot of code, you should generally split it in several projects: you can then analyse projects in parallel.

Pierre-Yves

To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/86c403d4-9dd5-4232-b6e4-4ca34125f688%40googlegroups.com.

[b...@hotmail.com]

These are the sensor entries found in the file from the start to 20:26

19:51:58.876 INFO  - Sensor Lines Sensor (wrapped)

19:51:59.294 INFO  - Sensor Lines Sensor (wrapped) (done) | time=418ms

19:51:59.294 INFO  - Sensor QProfileSensor

19:51:59.303 INFO  - Sensor QProfileSensor (done) | time=9ms

19:51:59.303 INFO  - Sensor org.sonar.plugins.stylecop.StyleCopSensor

[many lines...]

19:52:05.426 INFO  - Sensor org.sonar.plugins.stylecop.StyleCopSensor (done) | time=6122ms

19:52:05.426 INFO  - Sensor JavaScriptSquidSensor

[many lines...]

19:52:56.563 INFO  - Sensor JavaScriptSquidSensor (done) | time=51137ms

19:52:56.563 INFO  - Sensor org.sonar.plugins.resharper.CSharpReSharperProvider$CSharpReSharperSensor

[many lines...]

20:22:56.057 INFO  - Sensor org.sonar.plugins.resharper.CSharpReSharperProvider$CSharpReSharperSensor (done) | time=1799494ms

20:22:56.058 INFO  - Sensor WebSensor

[many lines...]

20:23:00.240 INFO  - Sensor WebSensor (done) | time=4182ms

20:23:00.240 INFO  - Sensor org.sonar.plugins.ndepend.NDependSensor

[many lines...]

20:23:50.100 INFO  - Sensor org.sonar.plugins.ndepend.NDependSensor (done) | time=49860ms

20:23:50.100 INFO  - Sensor org.sonar.plugins.csharp.CSharpSensor

[many lines...]

20:23:57.750 INFO  - Sensor org.sonar.plugins.csharp.CSharpSensor (done) | time=7650ms

20:23:57.750 INFO  - Sensor org.sonar.plugins.csharp.CSharpFxCopProvider$CSharpFxCopSensor

[many lines...]

20:24:09.320 INFO  - Sensor org.sonar.plugins.csharp.CSharpFxCopProvider$CSharpFxCopSensor (done) | time=11570ms

20:24:09.320 INFO  - Sensor org.sonar.plugins.csharp.CSharpCodeCoverageProvider$CSharpCoverageReportImportSensor

[many lines...]

20:24:10.987 INFO  - Sensor org.sonar.plugins.csharp.CSharpCodeCoverageProvider$CSharpCoverageReportImportSensor (done) | time=1667ms

20:24:10.987 INFO  - Sensor org.sonar.plugins.csharp.CSharpUnitTestResultsProvider$CSharpUnitTestResultsImportSensor

20:24:10.987 INFO  - Sensor org.sonar.plugins.csharp.CSharpUnitTestResultsProvider$CSharpUnitTestResultsImportSensor (done) | time=0ms

20:24:10.987 INFO  - Sensor SCM Sensor (wrapped)

20:24:10.988 INFO  - No SCM system was detected. You can use the 'sonar.scm.provider' property to explicitly specify it.

20:24:10.988 INFO  - Sensor SCM Sensor (wrapped) (done) | time=1ms

20:24:10.988 INFO  - Sensor org.sonar.plugins.javascript.lcov.UTCoverageSensor

20:24:10.988 INFO  - Sensor org.sonar.plugins.javascript.lcov.UTCoverageSensor (done) | time=0ms

20:24:10.988 INFO  - Sensor org.sonar.plugins.javascript.lcov.ITCoverageSensor

20:24:10.988 INFO  - Sensor org.sonar.plugins.javascript.lcov.ITCoverageSensor (done) | time=0ms

20:24:10.988 INFO  - Sensor Code Colorizer Sensor (wrapped)

20:24:12.528 INFO  - Sensor Code Colorizer Sensor (wrapped) (done) | time=1540ms

20:24:12.528 INFO  - Sensor CPD Sensor (wrapped)

[many lines...]

20:24:23.128 INFO  - Sensor CPD Sensor (wrapped) (done) | time=10600ms

[many lines...]

20:24:23.555 INFO  - Sensor Lines Sensor (wrapped)

20:24:23.555 INFO  - Sensor Lines Sensor (wrapped) (done) | time=0ms

20:24:23.555 INFO  - Sensor QProfileSensor

20:24:23.556 INFO  - Sensor QProfileSensor (done) | time=1ms

20:24:23.556 INFO  - Sensor org.sonar.plugins.resharper.CSharpReSharperProvider$CSharpReSharperSensor

[many lines...]

20:26:04.904 INFO  - Sensor org.sonar.plugins.resharper.CSharpReSharperProvider$CSharpReSharperSensor (done) | time=101348ms

20:26:04.904 INFO  - Sensor org.sonar.plugins.ndepend.NDependSensor

David

[Pierre-Yves Nicolas]

It seems that the ReSharper plugin takes most of the time in these logs.

What about the 6-hour hole of your previous e-mail? Did you identify which sensor was active at that time?

Pierre-Yves

To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/f839a7c8-9a94-4156-87d6-d320a5af517e%40googlegroups.com.

[b...@hotmail.com]

There are no sensor entries before those listed but perhaps those entries:

13:28:07.145 DEBUG - Scanning MyProject:Dev:Invoice/js/spec/invoicelinesSpec.js

19:43:02.965 DEBUG - Scanning MyProject:Dev:Invoice/template/CCSD.html

seem to indicate the freeze is during pre-processing, before sensors start...?

[Pierre-Yves Nicolas]

Could you share the lines which are just before this series of "DEBUG - Scanning"?

To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/e9a90341-4be6-483c-a9d6-ec67e582f868%40googlegroups.com.

[David]

They are shown above in my second posting on this thread. 

There are 2000 more lines back to the start but here is back as far as the language detection.

13:21:46.142 DEBUG - Language of file 'ViewCover/js/PolicyDetails.js' is detected to be 'js'

13:21:46.142 DEBUG - Language of file 'ViewCover/js/ILDetails.js' is detected to be 'js'

13:21:46.144 DEBUG - Language of file 'ViewCover/js/spec/PolicyDetailsSpec.js' is detected to be 'js'

13:21:46.144 DEBUG - Language of file 'ViewCover/js/spec/CoverModulesSpec.js' is detected to be 'js'

13:21:46.144 DEBUG - Language of file 'ViewCover/js/spec/ILDetailsSpec.js' is detected to be 'js'

13:21:46.145 DEBUG - Language of file 'ViewCover/js/ViewCover.js' is detected to be 'js'

13:21:46.145 DEBUG - Language of file 'ViewCover/js/ViewCoverModule.js' is detected to be 'js'

13:21:46.148 DEBUG - Language of file 'Search/Index.html' is detected to be 'web'

13:21:46.149 INFO  - 1506 files indexed

13:21:46.149 INFO  - 234 files ignored because of inclusion/exclusion patterns

13:21:46.417 INFO  - Quality profile for cs: Papillon

13:21:46.417 INFO  - Quality profile for js: Papillon

13:21:46.417 INFO  - Quality profile for web: Papillon

13:21:46.417 DEBUG - Scanning MyProject:5119644d:XXX.YYY.Web:Dev:Common/Template/AddUserEventLogTemplate.html

13:21:46.443 DEBUG - Scanning MyProject:5119644d:XXX.YYY.Web:Dev:Common/Template/AuthorizedInvoicePopupTemplate.html

13:21:46.450 DEBUG - Scanning MyProject:5119644d:XXX.YYY.Web:Dev:Common/Template/ExcessHistory.html

[many identical lines for each file]

13:22:13.554 DEBUG - Scanning MyProject:5119644d:XXX.YYY.Web:Dev:Invoice/js/spec/FetchInvoiceLinesRulesSpec.js

13:22:13.599 DEBUG - Scanning MyProject:5119644d:XXX.YYY.Web:Dev:Invoice/js/spec/GenerateInvoiceAssessmentIdSpec.js

13:22:13.610 DEBUG - Scanning MyProject:5119644d:XXX.YYY.Web:Dev:Invoice/js/spec/InvoiceAssessmentHistorySpec.js

13:22:13.637 DEBUG - Scanning MyProject:5119644d:XXX.YYY.Web:Dev:Invoice/js/spec/InvoiceAssessmentSpec.js

13:27:15.910 DEBUG - Scanning MyProject:5119644d:XXX.YYY.Web:Dev:Invoice/js/spec/InvoiceCCSDAndItemCodeSearchSpec.js

13:28:04.376 DEBUG - Scanning MyProject:5119644d:XXX.YYY.Web:Dev:Invoice/js/spec/InvoiceCalculationSpec.js

13:28:04.407 DEBUG - Scanning MyProject:5119644d:XXX.YYY.Web:Dev:Invoice/js/spec/InvoiceClaimAssesmentSpec.js

13:28:04.449 DEBUG - Scanning MyProject:5119644d:XXX.YYY.Web:Dev:Invoice/js/spec/InvoiceHeaderSpec.js

13:28:04.495 DEBUG - Scanning MyProject:5119644d:XXX.YYY.Web:Dev:Invoice/js/spec/InvoiceInfoAssessmentSpec.js

13:28:04.533 DEBUG - Scanning MyProject:5119644d:XXX.YYY.Web:Dev:Invoice/js/spec/InvoiceLineAssessmentSpec.js

13:28:04.691 DEBUG - Scanning MyProject:5119644d:XXX.YYY.Web:Dev:Invoice/js/spec/InvoiceManualEventLogSpec.js

13:28:07.103 DEBUG - Scanning MyProject:5119644d:XXX.YYY.Web:Dev:Invoice/js/spec/InvoicePolicyDetailsSpec.js

13:28:07.113 DEBUG - Scanning MyProject:5119644d:XXX.YYY.Web:Dev:Invoice/js/spec/InvoiceSpec.js

13:28:07.126 DEBUG - Scanning MyProject:5119644d:XXX.YYY.Web:Dev:Invoice/js/spec/ItemCodeSearchSpec.js

13:28:07.141 DEBUG - Scanning MyProject:5119644d:XXX.YYY.Web:Dev:Invoice/js/spec/NewInvoiceLineSpec.js

13:28:07.145 DEBUG - Scanning MyProject:5119644d:XXX.YYY.Web:Dev:Invoice/js/spec/invoicelinesSpec.js

19:43:02.965 DEBUG - Scanning MyProject:5119644d:XXX.YYY.Web:Dev:Invoice/template/CCSD.html

[Günter Wirth]

Hi Ann,

That sounds really good.

... but can be configured to use more.

How can I increase the number of used threads? Where can I set this option?

Regards,
Günter

[G. Ann Campbell]

From the docs: 

 You can control the number of Analysis Reports that can be processed at a time in $SQ_HOME/conf/sonar.properties (see sonar.ce.workerCount - Default is 1).

If you follow the link, you'll notice that the header on these docs pages is red. That's because they're for a version that hasn't been released yet.

Ann

---

G. Ann CAMPBELL | SonarSource

Product Owner

http://sonarsource.com

To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/621b75b8-e94b-4faa-8688-d6efb57c425f%40googlegroups.com.

[Pierre-Yves Nicolas]

David,

The problem may be related to the issue exclusion settings.

In SonarQube administration, go to "Analysis Scope" and then "Issues".

You may have some costly regular expressions.

Pierre-Yves

To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/7e29cd3b-8e05-469d-a8e3-de5a70ed2780%40googlegroups.com.

[David]

There are only 3 for sonar.issue.ignore.allfile:

.*auto-generated.*

.*Designer generated code.*

// <auto-generated>

Thanks,

David

[David]

Adding the offending files to the exclusions list sped up analysis to 59mins which is a great improvement.

Subsequent to that run we also removed the redundant 3rd regex below but this did not increase it further.

Thanks for your help.

David