Performance optimizations for the traceability matrix / make it configurable
A customer presented us a situation where there are 72 calls to Jira (2333 rows, that is understandable but not optimal) and it only stops because it times out. We need to help them.
Many requests to Jira when there are just a few columns and 2333 rows. To do: Check whether there can be fewer requests.
Can they configure/increase the maximum number of requests to Jira, as a workaround?
When exporting to XLS, the whole matrix (without pagination) should be exported, even if it takes time.
It is not possible to improve the performance directly. All requests to Jira are necessary.
We've displayed the list of requests, so the user can understand.
We've made a number of limits configurable. If administrators diagnose slowness, limits can be reduced.
There is no limit to the number of Jira requests in the XLS export, but there is a timeout (2 minutes by default).
Not included here
Discuss with Xray on how to retrieve the data in bulk - discussed in RY-675.
New limits implemented, can be modified in the administration:
Number of Jira calls per matrix: It used to be 60, it is increased to 1000 by default and configurable.
Number of Jira issues: Increased to 5000, configurable.
Timeout for the traceability matrix: 30s, configurable.
Timeout when exporting: 2 minutes by default, configurable, and the number of Jira calls doesn't apply to the export.
If you are a system administrator, you may want to look into lowering the export timeout to 30s if you are meeting performance problems, and ask your users not to export the whole Internet with this matrix.