Our organization has been using ALM 25.3 for enterprise risk management and we’ve accumulated over 50,000 requirements with extensive traceability links to risks, tests, and defects. The traceability matrix reports have become painfully slow - some queries timeout after 5+ minutes.
We’re exploring optimization strategies for traceability matrix performance. Key areas we’re investigating:
- Database indexing on relationship tables that store traceability links
- Query filtering strategies to scope reports to relevant subsets
- Caching mechanisms for frequently accessed traceability data
- Incremental update approaches instead of full matrix regeneration
Our database team noticed the REQ_LINK and AUDIT_LOG tables are massive with millions of rows. Basic relationship queries are doing full table scans. We’ve added some indexes but want to understand best practices from teams managing similar scale.
Anyone running large-scale traceability implementations? What performance tuning approaches have worked for your environment?
For compliance, we maintain separate archived traceability snapshots taken at each release milestone. These are stored as static reports rather than dynamically queried. This satisfies audit requirements while keeping operational queries fast. Archive historical data to separate tables or schemas after release completion.
We faced similar issues at 40K requirements. The key breakthrough was implementing query scoping. Instead of generating full traceability matrices across all requirements, we:
- Added filters for requirement status (active only)
- Scoped by project or release
- Limited depth of traceability traversal (2-3 levels max)
- Used date range filters to focus on recent changes
This reduced query result sets by 70-80% and brought response times under 30 seconds.
The query scoping approach sounds promising. We currently generate matrices for entire product lines which includes both active and archived requirements. Filtering to active-only would cut our dataset significantly. How did you handle compliance requirements for historical traceability visibility?
Caching is critical for traceability performance. ALM supports result caching for reports and queries. Configure cache settings in Site Administration:
-- Example cache configuration
SET traceability.cache.enabled = true
SET traceability.cache.ttl = 3600
SET traceability.cache.max_entries = 10000
This caches frequently accessed traceability queries for an hour. For static relationships that rarely change, this eliminates redundant database hits.