...

1.  Creating a Test Plan from within some Test Repository folder that has many Tests and sub-folders can take some time, if you choose to replicate the folder structure into the destination Test Plan Board. However, this is temporary.
2.  Avoid many folders shown at the same time as it will impact browser performance at some time. You can do this by limiting of direct child folders you create at a given parent folder and by using the "Expand all" moderately. The amount of folders you have does not affect by itself your Jira backend performance though.

Test Executions

1. Image Modified Reuse existing Test Executions (and related Test Runs), if possible, to make calculations faster througout the application and thus make reports and some panels, for example, also faster
   1. if you don't need historical data of interim builds, you may reuse an existing Test Execution and update the corresponding Test Runs. During CI, depending on the endpoint being used, you may specify a Test Execution issue key. In such case, Xray will overwrite the existing Test Runs information, or add new ones if the Test is not yet part of the Test Execution.
2.  Clean-up old, unneeded executions related data, to make calculations faster througout the application and thus make reports and some panels, for example, also faster

   1. If your organization performs a high number of Test Executions (consequently creating also a high number of Test Runs) we recommend deleting old Test Executions issues from time to time. This recommendation applies to organizations that import many automated executions daily using the REST API.

      The clean-up process must be scheduled for a low Jira usage period because when Test Executions are deleted, Xray will re-calculate TestRunStatus and Requirement Status. This might temporarily slow down the Jira instance depending on the amount of issues affected.

   2. Deleting Test Runs can affect the calculated and consolidated status of your Tests and of your requirements for all scopes (e.g. versions or Test Plans + Test Environments); please use carefully
3.  Although there isn’t an hard limit, we recommend having no more than 2000 Tests in a given Test Execution mostly to ease their management. This limit may be easily superseded depending on Jira instance deployment configuration.

...

1.  Xray provides a setting "Max number of Tests per Test Plan" where you may define a soft limit for the number of Tests within Test Plans. Although you may adjust this value, we recommend having no more than 2000 Tests in a given Test Plan:
   1. to ease their management;
   2. and to make it more performant and lighter.
   This limit may be easily superseded depending on Jira instance deployment configuration.
   Note that a Test Plan aggregates and consolidates the results of the related Test Executions and Tests, thus the overall number of Test Runs you'll have can add some overhead to the calculation of the consolidated results.

Test Plan Board

1. Image RemovedImage Added Using the Test Plan Board as means to do operations over certain Tests of the Test Plan (e.g. schedule Test Executions for them) and to track results can be more efficient than using the Test Plan issue screen. Although the previous two are not equivalent, the Board provides essentialy the same operations while being lighter most of the times as it not shows all the information you can see in the Test Plan issue screen.
2.  Avoid many folders shown at the same time as it will impact browser performance at some time. You can do this by limiting of direct child folders you create at a given parent folder and by using the "Expand all" moderately. The amount of folders you have does not affect by itself your Jira backend performance though.

...

1.  Review the "Max results per request" setting in the the Miscellaneous administration settings as it controls the pagination on the REST API calls. The default value should be ok.
2.  export results results - custom fields
3. https://confluence.xpand-it.com/display/XRAY/Export+Execution+Results+-+REST
4. diamantino vai ver o q mandou pra ubs
5.  Limit API calls (Jira and Xray related ones) using a reverse proxy
   1. Evaluate what REST API calls are being used, discuss their real need with users
      1. Make sure that pagination is being used on the REST API calls
   2. Restrict access to REST API calls
      1. Limit access to well-known hosts/applications

...

1.   Using unoptimized JQL queries can degrade performance substantially
   1. most times this happens because users don't understand how JQL works first of all; JQL is not like SQL (see Understanding JQL Performance). Thus, filtering issues by project by adding the "project = <xxx>" clause is not the same as specifying the project as argument to the subsequent JQL function.
      
      1. Example: 

         1. Use

            issue in requirements('OK','CALC')

            ...instead of ...

            project = 'CALC' and issue in requirements('OK')
            
            

2.  Some JQL functions, such as the ones dealing with requirement coverage, may be more intensive than other ones, since Xray may have to, for example, load all the related Test Runs in order to obtain relevant data. The following JQL 
   1. PIOR testPlanTests() - 
   2. requirements(), , testPlanTestswith dates
   3. testExecutionTests() - testExecutionTests(diamantino tem duvidas?)  - whenever filtering by tests/requirements in a given status; it will depend on the amount of Tests you have on the Test Execution
   4. parentRequirements() (diamantino tem duvidas?)  - depending on the amount of requirements and sub-requirements you have, it can take a while to complete and require some resources

...

1.  Xray provides some specific custom fields that calculate their values on the fly. This means that you should have that in mind, specially if you're including them in tables/issue listings/gadgets.

Test Execution Defects

test set status

tests count

Reports and Gadgets

1.  One way of doing reporting is by using gadgets. Gadgets are great to share information between team members and even between different teams; however, if not use carefully, they can degrade JIRA performance if all users have the same report on their dashboard as they will probably generate multiple requests once users access the dashboard. Thus, use carefully most intensive gadgets such as the "Historical Daily Requirement Coverage" and the "Tests Evolution" gadget and others that do aggregations (e.g. "Test Runs Summary" gadget). Gadgets that just "list" entities should not affect performance significatively.
2.  Limit the target issues for the reports/gadget CONF, e.g. generate the Overall Requirement Coverage (report/gadget) just for issues that you really need and not all Jira requirements or projects.

...

1. Use dashboards to have the high-level overview and the things that matter
2. Avoid creating highly complex dashboards or dashboards
3. Try to normalize the dashboards and make them like a standard organization wid
   1. facilitates communication
   2. avoids “wrong” usage
4. Choose properly the filters you use for each gadget, in order to restrict the amount of issues that will be processed
5. refresh times

Custom Reports

1.  If possible, use eazyBI for making custom table/chart based reports with drill-down capabilities; it is highly flexible and works in its own database, thus not impacting Jira unless the database is hosted in the same instance of Jira server/database
2.  If using the Xporter app to build custom PDF, Word or Excel based reports, then please see Xporter specific recommendations.

...

• quais outros settings podem ter mais impacto na performance? separation of concerns?estado calcula com base no testset; cuidado ao mudar

Your own custom fields

1.  Beware with calculated custom fields implemented using some customization app (e.g. Jira Misc Custom Fields, ScriptRunner, etc) as they will be calculated each time they're accessed and they can impact things such as
   • indexing time
   • REST API calls (e.g. whenever searching issues)
   • on listings (e.g. on Issues search page, Filters Results gadget, Xray tabular sections) if they're included as columns 
2.  Adding a lot of custom fields on Jira will add some overhead on performance; therefore, Atlassian itself recommends a responsible usage of custom fields

...

1.  Don't use complex workflows for Xray entities as it will harden their usage

Reindex???

?? avaliar questao de tirar searcher ao Test Execution Defects

bulk cloning test plans ou test executions using addons

Data Center Tips

1.  Review Atlassian's best practices for Data Center and the Node sizing overview for Atlassian Data Center article
2.  Configure your load balancer properly to use dedicated nodes for REST API calls, which can reduce impact on other application nodes
3. Integration with other apps
   1.  See eazyBI's Data Center related recommendations here

...