Problem : -
Currently, PurlDB processes repeated queries for the same PURL without any caching mechanism. This leads to redundant database/API calls, especially during large-scale operations such as SBOM imports or repeated metadata lookups.
Proposed Solution :-
Introduce a caching layer to store frequently accessed PURL metadata. This could include:
- In-memory caching (e.g., LRU cache)
- Optional Redis-based caching for scalability
- Cache invalidation strategy when data updates
The caching should be applied to:
- metadata queries
- version lookups
- URL retrieval functions
Benefits :-
- Improved performance for repeated queries
- Reduced database/API load
- Faster SBOM processing
- Better scalability for large datasets
Additional Context :-
Similar issues around repeated metadata access and inefficiencies have been observed in related tools interacting with PurlDB. Adding caching would improve overall system responsiveness and usability.
Problem : -
Currently, PurlDB processes repeated queries for the same PURL without any caching mechanism. This leads to redundant database/API calls, especially during large-scale operations such as SBOM imports or repeated metadata lookups.
Proposed Solution :-
Introduce a caching layer to store frequently accessed PURL metadata. This could include:
The caching should be applied to:
Benefits :-
Additional Context :-
Similar issues around repeated metadata access and inefficiencies have been observed in related tools interacting with PurlDB. Adding caching would improve overall system responsiveness and usability.