Skip to content

Conversation

@gbennett-squarespace
Copy link

@gbennett-squarespace gbennett-squarespace commented Apr 24, 2025

Description

Adds a number of indexes (mostly composite) to reduce load (primarily CPU) and response time. I'm not a Java dev by any means, while I believe I'm creating the indexes correctly please double check my work here.

Addressed Issue

Detailed statistics and information is available in #4869 . This should fix the CPU utilization and response time for the queries that are causing the highest load in our environment. There are likely a fair number of other indexes that could be added to improve performance, I tried to limit this to only the ones that had the highest cost in our environment.

Additional Details

These indexes were tested manually via index creation:

CREATE INDEX CONCURRENTLY "DEPENDENCYMETRICS_COMPOSITE_LAST_OCCURRENCE_IDX"
  ON public."DEPENDENCYMETRICS"("COMPONENT_ID","LAST_OCCURRENCE" DESC);

CREATE INDEX CONCURRENTLY COMPONENT_COMPOSITE_PROJECT_ID_IDX
  ON public."COMPONENT"("PROJECT_ID", "ID" DESC);

CREATE INDEX CONCURRENTLY PROJECTMETRICS_COMPOSITE_LAST_OCCURRENCE_IDX
  ON public."PROJECTMETRICS"("PROJECT_ID", "LAST_OCCURRENCE" DESC);

CREATE INDEX CONCURRENTLY VULNERABILITY_COMPOSITE_SOURCE_VULNID_IDX
  ON public."VULNERABILITY"("SOURCE", "VULNID");

CREATE INDEX CONCURRENTLY FINDINGATTRIBUTION_COMPOSITE_VULNERABILITY_ATTRIBUTED_IDX
  ON public."FINDINGATTRIBUTION"(
    "COMPONENT_ID",
    "VULNERABILITY_ID",
    "ATTRIBUTED_ON" DESC
  );

CREATE INDEX CONCURRENTLY ANALYSIS_COMPOSITE_VULNERABILITY_PROJECT_IDX
  ON public."ANALYSIS"(
    "COMPONENT_ID",
    "VULNERABILITY_ID",
    "PROJECT_ID"
  );

CREATE INDEX CONCURRENTLY ANALYSIS_COMPOSITE_VULNERABILITY_PROJECT_SUPPRESSED_IDX
  ON public."ANALYSIS"(
    "COMPONENT_ID",
    "VULNERABILITY_ID",
    "PROJECT_ID",
    "SUPPRESSED"
  );

CREATE INDEX CONCURRENTLY PROJECT_ACTIVE_IDX
  ON public."PROJECT"("ID")
  WHERE "ACTIVE" = true;

Checklist

  • I have read and understand the contributing guidelines
  • This PR fixes a defect, and I have provided tests to verify that the fix is effective
  • This PR implements an enhancement, and I have provided tests to verify that it works as intended
  • This PR introduces changes to the database model, and I have added corresponding update logic
  • This PR introduces new or alters existing behavior, and I have updated the documentation accordingly

@gbennett-squarespace gbennett-squarespace force-pushed the DEPENDENCYMETRICS_INDEX_LAST_OCCURRENCE branch from dc6227d to 2113884 Compare April 24, 2025 01:02
@owasp-dt-bot
Copy link

owasp-dt-bot commented Apr 26, 2025

🎉 Snyk checks have passed. No issues have been found so far.

security/snyk check is complete. No issues have been found. (View Details)

@gbennett-squarespace
Copy link
Author

Fixed the linting errors in the last run.

@gbennett-squarespace
Copy link
Author

Added the missing @index reference.

Copy link
Member

@nscuro nscuro left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some initial feedback. This would need to be thoroughly tested with other databases as well. Usually there is always something that, say, MSSQL doesn't support.

…sorting to indexes when they're being created.

Signed-off-by: gbennett <[email protected]>
@gbennett-squarespace
Copy link
Author

I've built this locally and run it against the H2 database with no errors/issues (including testing loading a BOM and analyzing).

I'll work on testing other DBs.

@gbennett-squarespace
Copy link
Author

gbennett-squarespace commented May 7, 2025

Tested with MS SQL and Postgres without issues.

I did get the database to build successfully with MySQL, I wasn't able to actually connect to it and test functionality (issue with getting the frontend to hit the backend, something on my end I'm sure). Everything did start up though with no errors in the logs.

@gbennett-squarespace
Copy link
Author

gbennett-squarespace commented May 28, 2025

@nscuro , you want to take another look at this?

I'm guessing I need to bump the version of DT I'm pointing at for the upgrade piece. :)

@nscuro
Copy link
Member

nscuro commented May 29, 2025

I'll have a other look and run some tests with the various databases over the coming days.

@codacy-production
Copy link

Coverage summary from Codacy

See diff coverage on Codacy

Coverage variation Diff coverage
+0.01% (target: -1.00%) (target: 70.00%)
Coverage variation details
Coverable lines Covered lines Coverage
Common ancestor commit (7b81bc2) 23968 19319 80.60%
Head commit (15c1842) 24029 (+61) 19371 (+52) 80.62% (+0.01%)

Coverage variation is the difference between the coverage for the head and common ancestor commits of the pull request branch: <coverage of head commit> - <coverage of common ancestor commit>

Diff coverage details
Coverable lines Covered lines Diff coverage
Pull request (#4870) 0 0 ∅ (not applicable)

Diff coverage is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified: <covered lines added or modified>/<coverable lines added or modified> * 100%

See your quality gate settings    Change summary preferences

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants