Long loading times at project dashboard since upgrade from 9.9.6 to 2025.1

SonarQube Server / Community Build
,
1

Unfortunately, we’re currently having some trouble with our instance since we’ve upgraded our installation from 9.9.6 to the latest 2025.1 release.

Opening up the dashboard of a project results in a page loading time of round about 30 seconds. When inspecting network activity, we can see the dashboard is requesting data from /api/project_branches/list?project=Id which is the request responsible for the long loading time.

Currently our project has about 130 active branches, which never has caused any trouble in the past. Is this a known bug in the 2025.1 release or is there anything we can do in order to reduce this requests loading time?

We’re running a mssqlserver instance for our SonarQube installation. Also, we’re regularly executing the Ola Hallengren Scripts (IndexOptimize) on our database, so I think we should be good in that regard. Is there anything important we’re missing with that?

We usually don’t see our installation running out of memory, so I’m not sure if that is where our problem arises from as well. We only run out of memory when forcing it, by opening up 10+ tabs at the same time. In this case we see:

  • java.lang.OutOfMemoryError: Java heap space
  • com.microsoft.sqlserver.jdbc.SQLServerException: The connection is closed.
  • java.lang.OutOfMemoryError: Java heap space: failed reallocation of scalar replaced objects
  • Caused by: java.lang.RuntimeException: I/O reactor has been shut down

But as stated above, we don’t see anything of importance / regarding out of memory exceptions when experiencing these long loading times.

This issue only came up since we’ve upgraded from 9.9.6 to 2025.1. Before that, we never experienced any issues with the performance of our SonarQube server.

2

Hello,
Thank you for reporting this issue.
Are you using the dependency-check community plugin?

3

Hi @eric.giffon yes we are.

4

This plugin stores the dependency-check HTML report in a measure. This report can get pretty large (multiple MB). Following the compression of live measures (introduced in 10.8), the endpoint causing your issues is retrieving all the measures of all the branches. So, for 130 branches, it can get pretty slow.

This is not what measures are intended to be used for, we will discuss internally if we should restrict the measures’ size.

In the meantime, if you don’t care about displaying the HTML report through the SonarQube UI, you could stop loading the property sonar.dependencyCheck.htmlReportPath. This will prevent the report from being loaded in a measure. As a middle-ground, you could choose to load it only for the main branch or some branches.
As you analyze the branches without the report, the measures and memory usage will return to normal, and you will no longer experience those slowdowns.

5

Thanks for the clarification!

So what would be the best approach to get back to regular loading times for our existing projects with existing html reports in the analyses? Should we uninstall the plugin until we have html report free analyses for all branches?

6

You have two options:

  • Remove the plugin
  • As suggested in my previous reply, you can stop loading the analysis property sonar.dependencyCheck.htmlReportPath. If you do that you’ll still have the issues and metrics created by the plugin. You just won’t be able to access the HTML report in the project dashboard.

In both cases, you’ll only see an improvement after re-analyzing the branches.

7

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.