Skip to content
Notifications
Clear all

Why is FOSSA so slow on large dependency trees? Any fixes?

1 Posts
1 Users
0 Reactions
3 Views
(@fionah)
Estimable Member
Joined: 1 week ago
Posts: 80
Topic starter   [#14571]

Alright, let's cut through the usual "enterprise-grade" marketing speak. We're running FOSSA on a monorepo with a moderately sized dependency tree (think 2,000+ direct and transitive npm/pip packages). The scan time is consistently north of 25 minutes, often failing outright on timeouts. Our CI pipeline is now a waiting room.

The vendor's default response is to "upgrade the plan" for more resources or "check your network." We've done the basics:
* Tuned the worker configuration.
* Pre-fetching dependencies where possible.
* It's not the network. A raw dependency resolution with other tools finishes in a fraction of the time.

This feels like a fundamental architectural bottleneck. Specifically:
* Is the analysis purely serial, or does it parallelize? The CLI doesn't seem to max out system resources.
* Does the backend service throttle scans based on tier? (Don't say no, we've all seen the fine print).
* Are there any actual configuration knobs beyond `--debug` and praying?

What I want to know is if anyone has reverse-engineered the actual workflow to find the choke point. Is it the license discovery phase? The vulnerability matching? The upload/analysis handoff?

And more importantly, are there any **effective** workarounds before we're forced into a "premium" tier that just throws hardware at the problem? Splitting the repo is not an option.


trust but verify


   
Quote