Long UI loading times since upgrade to 2025.1

[falco-bethke]

Ref: https://community.sonarsource.com/t/long-loading-times-at-project-dashboard-since-upgrade-from-9-9-6-to-2025-1/134871/2

during update and table migration the SQ webserver needs to be pushed to a max of several GByte Mem to not run in OutOfMem/heap errors

Sonar says:

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.

their suggestion:

either

• Remove the plugin or
• 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.

I think there is a lack of communication in how DepedencyCheck info is passed to SQ?!

[xtermi2]

This issue should be fixed in the next sonarqube patch release 2025.1.1 See also

• https://community.sonarsource.com/t/out-of-memor-after-updateing-9-9-10-8/131649/20
• and https://sonarsource.atlassian.net/browse/SONAR-24522

[hsulriksensk]

This issue should be fixed in the next sonarqube patch release 2025.1.1 See also

• https://community.sonarsource.com/t/out-of-memor-after-updateing-9-9-10-8/131649/20
• and https://sonarsource.atlassian.net/browse/SONAR-24522

As I read the comment on the community post it will only fix this during migration, i.e. new scans after migration with 2025.1 will introduce this problem again.

The 2025.1.1 release will also include a change in the upgrade (from 10.7 or less) that will prevent the migration of large measures, which are the reason for the OOM and slowdowns.

[xtermi2]

As I read the comment on the community post it will only fix this during migration, i.e. new scans after migration with 2025.1 will introduce this problem again.

I can confirm this! We had to disable the dependency checker plugin after 2025.1.1 update because the measures in our project are ~60MB which lead quickly to OOM and ultra slow UI responses (until unusable UI) at relevant points.

[hsulriksensk]

We had to stop importing the HTML and if needed make it available as a CI artifact instead. We clean our database with UPDATE measures SET json_value = JSON_MODIFY(json_value, '$.report', NULL) until we've gotten ridd of all the htmlReportPath used in code. If the report is to be made available in SonarQube it probably need its own storage, and with up to 300MB reports, I think disk might be just as good as the database.

[Reamer]

I am back from parental leave and am playing with the idea of completely removing the HTML upload mechanism. The implementation was never clean anyway.

What are your thoughts?

[xtermi2]

@Reamer sounds good. We never used the HTML report in sonarqube. Just the issues are relevant to us.

[okgolove]

For postgresql this query worked for me (not the optimal one though):

UPDATE measures
SET json_value = (json_value::jsonb - 'report')::text
WHERE json_value::jsonb ->> 'report' ILIKE '%!DOCTYPE html%';

[rupreck]

I am back from parental leave and am playing with the idea of completely removing the HTML upload mechanism. The implementation was never clean anyway.

What are your thoughts?

Will the report still be able to be viewed? It will need to be available to help manage suppressions using the suppress button to extract the xml.

Ideally they would be presented neatly as Security Hotspots and there would be a button or content that contained the suppression XML to cut and past.

Using Sonar 25.2.0 the projects were reanalysed to generate the report and appear to load ok. The report when downloaded is only a couple of megabytes. We don't see a slowdown but do get the following warning on all projects now.

"A plugin is storing excessively large data in the following measure(s): 'report'. This is likely to cause significant SonarQube performance degradation and UI slowness. It is recommended to contact your administrator to disable the plugin or corresponding feature and reach out to the plugin maintainer for further assistance."

This is even though they have stopped the loading of all measures on startup in 25.2.0, and refer to this plugin in the ticket

https://sonarsource.atlassian.net/issues/SONAR-24216?jql=fixVersion%20%3D%2016130%20AND%20issuetype%20%21%3D%20Task%20ORDER%20BY%20status%20DESC%2C%20created%20ASC%20

Thus the current implementation now works ok, we don't see the performance issues in 25.2.0, only the warning.

[github-actions[bot]]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 14 days.