Improve baseFolderInfo Performance and Memory Efficiency for Large Test Repositories

Problem Statement

The /rest/raven/1.0/folderStructure/baseFolderInfo endpoint does not scale efficiently for projects with large Test Repositories.

When the endpoint is called:

GET /rest/raven/1.0/folderStructure/baseFolderInfo?entityKey=<PROJECT_KEY>

the request eventually executes two independent repository-wide counting operations:

• countAllLeaves(entityKey)

• countAllOrphanLeaves(entityKey)

Both operations process the project's test population separately through Lucene.

For large projects containing approximately 90k-145k tests, this results in significant Lucene processing and object allocation. Observations indicate that a single request may generate more than 20 GB of heap allocation.

The issue is further amplified by:

• Lack of application-level caching for the calculated repository information.

• ResponseUtil.NO_CACHE, which prevents HTTP/browser caching.

• Repeated or burst requests from the UI.

• Repository-wide processing being performed independently for each request.

The current request flow is:

GET /rest/raven/1.0/folderStructure/baseFolderInfo?entityKey=AOSCXTEST
→ ProjectTestRepositoryResource.getBaseFolders(entityKey)
→ testRepositoryResourceHelper.getRepositoryInfo(entityKey)
→ TestRepositoryResourceHelperImpl.getRepositoryInfo(entityKey)
→ testRepositoryManager.getRepositoryInfo(entityKey)
→ TestRepositoryManagerImpl.getRepositoryInfo(entityKey)
→ countAllLeaves(entityKey) + countAllOrphanLeaves(entityKey)

As repository size increases, the cost of these operations can cause excessive transient heap usage, increased GC activity, long response times, and potentially Full GC or OOM conditions when several requests are executed within a short period.

Impact

Improving this flow would reduce the computational and memory cost associated with retrieving Test Repository information for large projects.

Expected improvements include:

• Lower heap allocation per baseFolderInfo request.

• Reduced Lucene processing and unnecessary object materialization.

• Reduced Full GC frequency and JVM memory pressure.

• Lower risk of OOM conditions under repeated requests.

• Faster response times for large Test Repositories.

• Better scalability as the number of tests in a project increases.

• Reduced impact of repeated or concurrent UI requests on overall Jira/Xray performance.

The improvement is particularly relevant for projects containing tens or hundreds of thousands of tests, where repository-wide counting operations become increasingly expensive.

How is the user solving it right now?

There is currently no direct workaround within Xray that reduces the processing cost of this endpoint.

Each request recalculates the repository information, even when the underlying repository data has not changed between requests.

Operational mitigations may include reducing repeated access to the affected functionality or increasing available JVM resources, but these approaches do not address the underlying scalability problem.