Cloud
Data Center 10.0
Versions

Jira Service Management guardrails

Performance and scaling

On this page

Related content

  • No related content found

Still need help?

The Atlassian Community is here for you.

Ask the community

The content of this page applies to the latest Long Term Support version, Jira Service Management 5.4.

Background

We’re committed to supporting the needs of our largest customers, and this includes continually improving the performance and scalability of our products. The amount of data in your instance can be a factor in performance and stability problems. As your instance grows, so does your risk of performance degradation over time. Often this is gradual degradation and can go unnoticed until you reach a point where it has a significant impact on your team.

In the table below, we’ve described the performance and stability impacts that we’ve observed and suggested some actions you can take to reduce your risk. The guardrails are based on real-world experiences with some of our largest customers and performance testing on a standalone Jira Service Management instance. Note that the guardrails won’t necessarily be representative of every organization’s experience.

Ways you can reduce the risk of experiencing serious performance and stability problems may include:

  • application changes, such as upgrading to a newer application version to get the benefit of performance improvements, or changing the way users are managed.

  • infrastructure changes, such as increasing memory, CPU, or running a cluster or mirrors.

  • data cleanup activities to reduce your footprint, such as archiving or breaking up monolith sites.

It’s important to note that these aren’t hard limits, and some of your product instances may already exceed these thresholds. There are a number of factors, including the interplay between different data types, and site load, which will influence whether you experience the potential impacts listed below, and to what degree. As with any type of risk, it’s essential to identify the risk and make a plan, so you can prioritize those actions that will help you reduce the probability of future performance problems.

What are guardrails?

Product Guardrails are data type recommendations designed to help you identify potential risks and aid you making decisions about next steps in your instance optimization journey.

Jira Service Management guardrails

The following guardrails are provided to help you identify and mitigate scale risks, and make decisions about cleaning up your instance.

Service Level Agreements (SLAs)

Content type

Number of SLAs per project 

Guardrail

30 SLAs per project

How to find this number

To find the number SLAs per project execute the following SQL query:

SELECT p.pkey AS "Project Key", 
	COUNT(*) AS "SLA Count"
FROM "AO_54307E_TIMEMETRIC" tm
LEFT JOIN "AO_54307E_SERVICEDESK" sd ON tm."SERVICE_DESK_ID" = sd."ID"
LEFT JOIN "project" p ON sd."PROJECT_ID" = p.id
GROUP BY p.pkey ORDER BY p.pkey;

Risks

We've observed these problems when operating above this guardrail:

  • The time cost for SLA calculation grows linearly with the number of SLAs per project.

  • SLAs may be calculated and available on the issues with a delay.

Mitigation options

SLA goals

Content type

Number of SLA goals

Guardrail

100 goals per SLA
400 SLA goals per project

How to find this number

To find the number of goals per SLA execute the following SQL query:

SELECT g."TIME_METRIC_ID" AS "SLA ID", COUNT(*) AS "Goals Count"
FROM "AO_54307E_GOAL" g
GROUP BY g."TIME_METRIC_ID" ORDER BY g."TIME_METRIC_ID";

To find the number of SLA goals per project execute the following SQL query:

SELECT p.pkey AS "Project Key", 
	COUNT(*) AS "Goals Count" 
FROM "AO_54307E_TIMEMETRIC" tm 
	LEFT JOIN "AO_54307E_SERVICEDESK" sd ON tm."SERVICE_DESK_ID" = sd."ID" 
	LEFT JOIN "project" p ON sd."PROJECT_ID" = p.id 
	LEFT JOIN "AO_54307E_GOAL" g ON g."TIME_METRIC_ID" = tm."ID"
GROUP BY p.pkey ORDER BY p.pkey;

Risks

We've observed these problems when operating above this guardrail:

  • The time cost for SLA calculation grows linearly with the number of SLA goals per project.

  • SLAs may be calculated and available on the issues with a delay

Mitigation options

  • Remove unnecessary SLA goals from the project.

  • Merge goals with the same targets where possible.

  • Distribute goals across multiple SLAs for easier maintainability.

  • Increase the SLA thread count if your environment can afford to do so. Learn how to configure the SLA thread count

  • When recalculating the SLAs, split them into multiple REST requests to execute them in parallel. Learn how to recalculate SLAs

Assets object schemas

Content type

Number of object schemas

Guardrail

1000 object schemas

How to find this number

The following REST endpoint retrieves high level statistics for each object schema /rest/insight/latest/analytics/schema.

To find the number of object schemas count the number of schemaId s within the returned response.

Format of returned response

[ { "schemaId":x,
"totalObjectCount":x,
"totalObjectTypeCount":x,
"totalAttributeCount":x,
"numberOfObjectsLinkedToIssues":x,
"numberOfObjectsWithUniqueAttribute":x,
"numberOfAutomationRules":0x
"numberOfAutomationIfs":x,
"numberOfAutomationWhens":x,
"numberOfAutomationThens":x,
"maxNumberOfObjectsByObjectType":x,
"averageNumberOfObjectsByObjectType":x,
"maxNumberOfAttributesByObjectType":x,
"averageNumberOfAttributesByObjectType":x },
...
]

Risks

We've observed these problems when operating above this guardrail:

  • Performance of creating new object schemas decreases.

  • Some AQL searches are slower.

  • General impact on Jira Service Management performance.

Mitigation options

  • Review and delete unused or unnecessary object schemas.

Assets object types

Content type

Number of object types per object schema

Guardrail

500 object types per object schema

How to find this number

The following REST endpoint retrieves high level statistics for each object schema: /rest/insight/latest/analytics/schema

To find the number of object types in an object schema refer to the totalObjectTypeCount field within the returned response.

Format of returned response

[{"schemaId":x,
"totalObjectCount":x,
"totalObjectTypeCount":x,
"totalAttributeCount":x,
"numberOfObjectsLinkedToIssues":x,
"numberOfObjectsWithUniqueAttribute":x,
"numberOfAutomationRules":0x
"numberOfAutomationIfs":x,
"numberOfAutomationWhens":x,
"numberOfAutomationThens":x,
"maxNumberOfObjectsByObjectType":x,
"averageNumberOfObjectsByObjectType":x,
"maxNumberOfAttributesByObjectType":x,
"averageNumberOfAttributesByObjectType":x},
...
]

Or, execute the following SQL query:

SELECT obj_schema."OBJECT_SCHEMA_KEY", 
	COUNT(*) AS "Object Types Count"
FROM "AO_8542F1_IFJ_OBJ_TYPE" AS obj_type
INNER JOIN "AO_8542F1_IFJ_OBJ_SCHEMA" AS obj_schema ON obj_type."OBJECT_SCHEMA_ID" = obj_schema."ID"
GROUP BY obj_schema."OBJECT_SCHEMA_KEY";

Risks

We've observed these problems when operating above this guardrail:

  • At 500 object types, we’ve noticed performance degradation on the following actions:

    • Expanding object types in an object schema

    • Viewing the Object Schemas page

    • Creating new objects

Mitigation options

  • Consider splitting the object schema into multiple object schemas with object types distributed across them.

Assets objects

Content type

Number of objects

Guardrail

500k objects per object schema (this limit doesn't include archived objects)

2 million objects per instance - where mostly heavy objects are used, that is objects that are:

  • linked to many other objects through inbound/outbound references

  • linked to many issues through custom fields

5 million objects per instance - where mostly light objects are used.

How to find this number

To find the number of objects per object schema we recommend either one of the following methods:

  • Go to Assets > Object Schemas

    Object schemas pageThe Object Schemas page

  • Use the following REST endpoint to retrieve high level statistics for each object schema /rest/insight/latest/analytics/schema. Refer to the totalObjectCount field for each object schema within the returned response.

    Format of returned response

    [{"schemaId":x,
    "totalObjectCount":x,
    "totalObjectTypeCount":x,
    "totalAttributeCount":x,
    "numberOfObjectsLinkedToIssues":x,
    "numberOfObjectsWithUniqueAttribute":x,
    "numberOfAutomationRules":0x
    "numberOfAutomationIfs":x,
    "numberOfAutomationWhens":x,
    "numberOfAutomationThens":x,
    "maxNumberOfObjectsByObjectType":x,
    "averageNumberOfObjectsByObjectType":x,
    "maxNumberOfAttributesByObjectType":x,
    "averageNumberOfAttributesByObjectType":x},
    ...
    ]

To find the number of objects in your instance, execute the following SQL query:

SELECT count(*) as "Asset Objects Per Instance"
FROM "AO_8542F1_IFJ_OBJ";

Risks

We've observed these problems when operating above this guardrail:

  • Assets search functionality linearly slows down as the number of objects grows.

  • Time needed to create objects with checks for unique attribute values grows linearly with the object count.

Mitigation options

  • With AQL search performing slower at higher object counts when searching for objects, we recommend narrowing the scope of the search from object schema to object type at the start of queries where possible. For example, our testing suggests that following AQL search objecttype=x and attribute_name having outboundReferences() runs twice as fast compared to attribute_name having outboundReferences().

  • Consider deleting objects where possible.

  • Consider increasing JVM memory above the recommended values .

Assets attributes

Content type

Number of attributes configured per object type

Guardrail

100 attributes configured per object type

How to find this number

The following REST endpoint retrieves high level statistics for each object schema /rest/insight/latest/analytics/schema.

To find the average and maximum number of attributes configured per object type refer to the maxNumberOfAttributesByObjectType and averageNumberOfAttributesByObjectType fields respectively within the returned response.

Format of returned response

[{"schemaId":x,
"totalObjectCount":x,
"totalObjectTypeCount":x,
"totalAttributeCount":x,
"numberOfObjectsLinkedToIssues":x,
"numberOfObjectsWithUniqueAttribute":x,
"numberOfAutomationRules":0x
"numberOfAutomationIfs":x,
"numberOfAutomationWhens":x,
"numberOfAutomationThens":x,
"maxNumberOfObjectsByObjectType":x,
"averageNumberOfObjectsByObjectType":x,
"maxNumberOfAttributesByObjectType":x,
"averageNumberOfAttributesByObjectType":x},
...
]

Or, execute the following SQL query:

SELECT obj_type."NAME",
	count(*) as "Attribute Count"
FROM "AO_8542F1_IFJ_OBJ_TYPE_ATTR" AS obj_attr_type
    INNER JOIN "AO_8542F1_IFJ_OBJ_TYPE" AS obj_type ON obj_type."ID" = obj_attr_type."OBJECT_TYPE_ID"
GROUP BY obj_type."NAME";

Risks

We've observed these problems when operating above this guardrail:

  • A noticeable slow down of the Object Graph view as you increase the number of attributes configured for an object type.

Mitigation options

  • Remove unnecessary attributes.

Assets attribute values

Content type

Number of attribute values stored for all objects

Guardrail

25 million attribute values - where mostly heavy objects are used, that is objects that are:

  • linked to many other objects through inbound/outbound references

  • linked to many issues through custom fields

50 million attribute values - where mostly light objects are used.

How to find this number

To find the number of attribute values in your instance, execute the following SQL query:

SELECT count(*) as "Assets Attribute Values per Instance"
FROM "AO_8542F1_IFJ_OBJ_ATTR_VAL";

Risks

We've observed these problems when operating above this guardrail:

  • A linear slowdown on Assets search functionality as the number of object attribute values grows. Especially in expensive search queries, for example queries that:

    • filter a large list of objects being linked to unresolved issues

    • use having outboundReferences()

  • Time needed to create objects with checks for unique attribute values grows linearly with the object count.

Note that when setting up this guardrail we assumed the worse case scenario where virtually all objects are created within a single object schema. When the objects are distributed more evenly, the performance impact may not be this significant.

Mitigation options

  • With AQL search performing slower at higher object counts when searching for objects, we recommend narrowing the scope of the search from object schema to object type at the start of queries where possible. For example, our testing suggests that following AQL search objecttype=x and attribute_name having outboundReferences() runs twice as fast compared to attribute_name having outboundReferences() .

  • Consider deleting objects where possible.

  • Consider increasing JVM Memory above the recommended values .

Last modified on May 3, 2024

Was this helpful?

Yes
No
Provide feedback about this article

Related content

  • No related content found
Powered by Confluence and Scroll Viewport.