Performance issue with 6.1.2
See original GitHub issueDescribe the bug On a maven project with hundreds of modules, generating an aggregated report with 6.1.2 is way slower than when using 6.1.1 version. When CVE databases are already cached, it takes around 1 or 2 minutes to generate the whole report with 6.1.1 version, but more than 30min when using 6.1.2.
When doing some profile, it looks like most of the time is spent inside method CveDB#simpleCPESearch()
Version of dependency-check used The problem occurs using version 6.1.2 of the maven plugin
Log file Here’s the plugin output when using version 6.1.1:
[INFO] Check for updates complete (152 ms)
[INFO] Analysis Started
[INFO] Finished Archive Analyzer (4 seconds)
[INFO] Finished File Name Analyzer (0 seconds)
[INFO] Finished Jar Analyzer (2 seconds)
[INFO] Finished Node.js Package Analyzer (2 seconds)
[INFO] Finished Dependency Merging Analyzer (5 seconds)
[INFO] Finished Version Filter Analyzer (0 seconds)
[INFO] Finished Hint Analyzer (0 seconds)
[INFO] Created CPE Index (1 seconds)
[INFO] Finished CPE Analyzer (18 seconds)
[INFO] Finished False Positive Analyzer (0 seconds)
[INFO] Finished NVD CVE Analyzer (1 seconds)
[INFO] Finished Node Audit Analyzer (0 seconds)
[INFO] Finished RetireJS Analyzer (0 seconds)
[INFO] Finished Sonatype OSS Index Analyzer (2 seconds)
[INFO] Finished Vulnerability Suppression Analyzer (2 seconds)
[INFO] Finished Dependency Bundling Analyzer (43 seconds)
[INFO] Analysis Complete (88 seconds)
And the output for 6.1.2:
[INFO] Check for updates complete (83 ms)
[INFO] Analysis Started
[INFO] Finished Archive Analyzer (4 seconds)
[INFO] Finished File Name Analyzer (0 seconds)
[INFO] Finished Jar Analyzer (3 seconds)
[INFO] Finished Node.js Package Analyzer (2 seconds)
[INFO] Finished Dependency Merging Analyzer (5 seconds)
[INFO] Finished Version Filter Analyzer (0 seconds)
[INFO] Finished Hint Analyzer (0 seconds)
[INFO] Created CPE Index (1 seconds)
[INFO] Finished CPE Analyzer (1524 seconds)
[INFO] Finished False Positive Analyzer (0 seconds)
[INFO] Finished NVD CVE Analyzer (1 seconds)
[INFO] Finished Node Audit Analyzer (0 seconds)
[INFO] Finished RetireJS Analyzer (0 seconds)
[INFO] Finished Sonatype OSS Index Analyzer (2 seconds)
[INFO] Finished Vulnerability Suppression Analyzer (2 seconds)
[INFO] Finished Dependency Bundling Analyzer (46 seconds)
[INFO] Analysis Complete (1597 seconds)
To Reproduce
mvn org.owasp:dependency-check-maven:6.1.2:aggregate
Expected behavior Performance should be reasonably similar to the previous version.
Issue Analytics
- State:
- Created 3 years ago
- Comments:5 (4 by maintainers)
Top Results From Across the Web
6.1.2. Debugging Data Transfer and Performance Issues - Intel
6.1.2. Debugging Data Transfer and Performance Issues. There are many possible reasons causing the PCIe link to stop transmitting data.
Read more >6.1.2 Evaluating the Effectiveness of Performance Measures
– The performance measures should drive decisions in support of strategic objectives. For example, a performance measure based on the amount of overtime ......
Read more >6.1.2 Driver Qualification File - fmcsa/csa
Inquiry to Previous Employers for Safety Performance History. Motor carriers must investigate, document, and retain all drivers' previous employment safety ...
Read more >Performance hit from 5.6.9 to 6.1.2 - Hibernate ORM
Now here the problem is that this is a Spring interface, so the source of the issue is still not clear, so I...
Read more >VMware vSphere Replication 6.1.2 Release Notes
For information about the vSphere Replication 6.1.2.x patch releases, ... virtual machine might cause performance problems as follows.
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
My guess from what I read, the REPLACE in the WHERE clause are causing a full table scan since the indexes can’t be used. A possible solution might be to have a new view with the values changed and indexes on the view.
The SELECT_SIMPLE_CPE_SEARCH query seems to be very unhappy in h2 with all the “Replace” calls.
Running EXPLAIN ANALYZE on the original query with a dummy value I get scanCount: 209373 and reads: 6423, and take 305 ms When I remove the Replace values, it’s 1 scan and takes 0-1 ms.