-
Suggestion
-
Resolution: Unresolved
-
None
Problem
The Domains page takes too long to completely load when there are hundreds of domains claimed.
Current Behaviour
When you first access the Domains page,
- It first loads the list domains which takes about ~250ms to load
https://admin.atlassian.com/gateway/api/adminhub/organization/<orgID>/domainClaims - Then there are 3 calls per domain triggered to lazy load the memberTotal, count and fetch data
GET https://admin.atlassian.com/gateway/api/adminhub/organization/<orgID>/domainClaims/<domain.name>/memberTotal GET https://admin.atlassian.com/gateway/api/admin/private/api/admin/v1/orgs/<orgID>/domains/<domain.name>/managed-accounts/count POST https://admin.atlassian.com/gateway/api/admin/private/api/admin/v1/orgs/<orgID>/managed-accounts/config/fetch
By the time the calls are all completed, and the page is fully populated, it'll have taken about 40s (for an org with 445 domains claimed) mark.
This becomes a problem for Enterprise organizations that need to claim thousands of domains
Suggested Solution
Improve the way the Domains page loads the valuable data (All/Managed/New accounts). Ideally, some sort of pagination for the response.
Why This Is Important
While the initial page load shows the list of domains, the valuable data is in the All/Managed/New accounts section which only comes after lazy loading. So when there are thousands of domains claimed it'll take too long.
Workaround
Currently, there is no known workaround for this behaviour. A workaround will be added here when available.
- mentioned in
-
Page Failed to load
[AX-359] Improve the page load time of the Domains page when there are a large number of domains claimed
| Component/s | Original: Domain Claim - Initial Setup [ 53302 ] | |
| Component/s | New: Domain Verification - Initial Setup [ 80145 ] | |
| Key | Original: ACCESS-1517 | New: AX-359 |
| Support reference count | Original: 3 | |
| Project | Original: Atlassian Guard [ 18910 ] | New: Admin Experience [ 24210 ] |
| Support reference count | Original: 2 | New: 3 |
| Support reference count | Original: 1 | New: 2 |
| Remote Link | New: This issue links to "Page (Confluence)" [ 781292 ] |
| Description |
Original:
h3. Problem
The Domains page takes too long to completely load when there are hundreds of domains claimed. h4. Current Behaviour When you first access the *Domains* page, # It first loads the list domains which takes about ~250ms to load {code:java} https://admin.atlassian.com/gateway/api/adminhub/organization/<orgID>/domainClaims {code} # Then there are 3 calls per domain triggered to lazy load the {{memberTotal}}, {{count}} and {{fetch}} data {code:java} GET https://admin.atlassian.com/gateway/api/adminhub/organization/<orgID>/domainClaims/<domain.name>/memberTotal GET https://admin.atlassian.com/gateway/api/admin/private/api/admin/v1/orgs/<orgID>/domains/<domain.name>/managed-accounts/count POST https://admin.atlassian.com/gateway/api/admin/private/api/admin/v1/orgs/<orgID>/managed-accounts/config/fetch {code} By the time the calls are all completed, and the page is fully populated, it'll have taken about 40s (for an org with 445 domains claimed) mark. This becomes a problem for Enterprise organizations that need to claim thousands of domains h3. Suggested Solution Improve the way the Domains page loads the valuable data (All/Managed/New accounts). Ideally, some sort of pagination for the response. h3. Why This Is Important While the initial page load shows the list of domains, the valuable data is in the All/Managed/New accounts section which only comes after lazy loading. So when there are thousands of domains claimed it'll take too long. h3. Workaround Currently, there is no known workaround for this behaviour. A workaround will be added here when available. |
New:
h3. Problem
The [Domains|https://support.atlassian.com/user-management/docs/verify-a-domain-to-manage-accounts/] page takes too long to completely load when there are hundreds of domains claimed. h4. Current Behaviour When you first access the *Domains* page, # It first loads the list domains which takes about ~250ms to load {code:java} https://admin.atlassian.com/gateway/api/adminhub/organization/<orgID>/domainClaims {code} # Then there are 3 calls per domain triggered to lazy load the {{memberTotal}}, {{count}} and {{fetch}} data {code:java} GET https://admin.atlassian.com/gateway/api/adminhub/organization/<orgID>/domainClaims/<domain.name>/memberTotal GET https://admin.atlassian.com/gateway/api/admin/private/api/admin/v1/orgs/<orgID>/domains/<domain.name>/managed-accounts/count POST https://admin.atlassian.com/gateway/api/admin/private/api/admin/v1/orgs/<orgID>/managed-accounts/config/fetch {code} By the time the calls are all completed, and the page is fully populated, it'll have taken about 40s (for an org with 445 domains claimed) mark. This becomes a problem for Enterprise organizations that need to claim thousands of domains h3. Suggested Solution Improve the way the Domains page loads the valuable data (All/Managed/New accounts). Ideally, some sort of pagination for the response. h3. Why This Is Important While the initial page load shows the list of domains, the valuable data is in the All/Managed/New accounts section which only comes after lazy loading. So when there are thousands of domains claimed it'll take too long. h3. Workaround Currently, there is no known workaround for this behaviour. A workaround will be added here when available. |
| Summary | Original: Improved performance for page load after claiming large number of domains on atlassian org | New: Improve the page load time of the Domains page when there are a large number of domains claimed |
| Description |
Original:
h3. Problem
Faster response time for domains page load after claiming a large number of domains. Currently, for each domain load, 3 AJAX calls per domain are triggered to lazy load in the member total/count/fetch data. h3. Steps to Reproduce # Claim a large number of domains(possibly in thousands) under Atlassian org. # It takes a long time for the page to load. 3 AJAX calls per domain that are triggered to lazy load in the member total/count/fetch data. h3. Suggested Solution It will be great if the page loading time is reduced. Ideally, some sort of pagination for the response. h3. Why This Is Important Faster loading time with better performance will help better performance for customers and delay in page loading outputs. h3. Workaround Currently, there is no known workaround for this behaviour. A workaround will be added here when available. |
New:
h3. Problem
The Domains page takes too long to completely load when there are hundreds of domains claimed. h4. Current Behaviour When you first access the *Domains* page, # It first loads the list domains which takes about ~250ms to load {code:java} https://admin.atlassian.com/gateway/api/adminhub/organization/<orgID>/domainClaims {code} # Then there are 3 calls per domain triggered to lazy load the {{memberTotal}}, {{count}} and {{fetch}} data {code:java} GET https://admin.atlassian.com/gateway/api/adminhub/organization/<orgID>/domainClaims/<domain.name>/memberTotal GET https://admin.atlassian.com/gateway/api/admin/private/api/admin/v1/orgs/<orgID>/domains/<domain.name>/managed-accounts/count POST https://admin.atlassian.com/gateway/api/admin/private/api/admin/v1/orgs/<orgID>/managed-accounts/config/fetch {code} By the time the calls are all completed, and the page is fully populated, it'll have taken about 40s (for an org with 445 domains claimed) mark. This becomes a problem for Enterprise organizations that need to claim thousands of domains h3. Suggested Solution Improve the way the Domains page loads the valuable data (All/Managed/New accounts). Ideally, some sort of pagination for the response. h3. Why This Is Important While the initial page load shows the list of domains, the valuable data is in the All/Managed/New accounts section which only comes after lazy loading. So when there are thousands of domains claimed it'll take too long. h3. Workaround Currently, there is no known workaround for this behaviour. A workaround will be added here when available. |
| Description |
Original:
h3. Problem
Faster response time for domains page load after claiming a large number of domains. Currently, for each domain load, 3 AJAX calls per domain are triggered to lazy load in the member total/count/fetch data. h3. Steps to Reproduce # Claim a large number of domains(possibly in thousands) under Atlassian org. # It takes a long time for the page to load. 3 AJAX calls per domain that are triggered to lazy load in the member total/count/fetch data. h3. Suggested Solution It will be great if the page loading time is reduced. Ideally, some sort of pagination for the response. h3. Why This Is Important Faster loading time with better performance will help better performance for customers and delay in page loading outputs. h3. Actual Results The page load is slower to load. h3. Workaround Currently, there is no known workaround for this behaviour. A workaround will be added here when available. |
New:
h3. Problem
Faster response time for domains page load after claiming a large number of domains. Currently, for each domain load, 3 AJAX calls per domain are triggered to lazy load in the member total/count/fetch data. h3. Steps to Reproduce # Claim a large number of domains(possibly in thousands) under Atlassian org. # It takes a long time for the page to load. 3 AJAX calls per domain that are triggered to lazy load in the member total/count/fetch data. h3. Suggested Solution It will be great if the page loading time is reduced. Ideally, some sort of pagination for the response. h3. Why This Is Important Faster loading time with better performance will help better performance for customers and delay in page loading outputs. h3. Workaround Currently, there is no known workaround for this behaviour. A workaround will be added here when available. |
| Description |
Original:
h3. Problem
Faster response time for domains page load after claiming a large number of domains. Currently, for each domain load, 3 AJAX calls per domain are triggered to lazy load in the member total/count/fetch data. h3. Steps to Reproduce # Claim a large number of domains(possibly in thousands) under Atlassian org. # It takes a long time for the page to load. 3 AJAX calls per domain that are triggered to lazy load in the member total/count/fetch data. h3. Suggested Solution It will be great if the page loading time is reduced. Ideally, some sort of pagination for the response. h3. Why This Is Important Faster loading time with better performance will help in h3. Actual Results The page load is slower to load. h3. Workaround Currently, there is no known workaround for this behaviour. A workaround will be added here when available. |
New:
h3. Problem
Faster response time for domains page load after claiming a large number of domains. Currently, for each domain load, 3 AJAX calls per domain are triggered to lazy load in the member total/count/fetch data. h3. Steps to Reproduce # Claim a large number of domains(possibly in thousands) under Atlassian org. # It takes a long time for the page to load. 3 AJAX calls per domain that are triggered to lazy load in the member total/count/fetch data. h3. Suggested Solution It will be great if the page loading time is reduced. Ideally, some sort of pagination for the response. h3. Why This Is Important Faster loading time with better performance will help better performance for customers and delay in page loading outputs. h3. Actual Results The page load is slower to load. h3. Workaround Currently, there is no known workaround for this behaviour. A workaround will be added here when available. |
With ~ 3300 domains (which is ~ 75% of what we know we need to claim for our org), this page is completely unusable. Depending on the user/browser, the page will either be blank with no errors (assume due to the huge amount of AJAX requests/DOM requests happening), or, if the domain list does load, the UI will start throwing errors for each domain "Something went wrong: please try later"
Assuming this is due to a REST API rate limit being hit.
As this page does not load, we are unable to:
This means we are unable to continue to secure our Atlassian Cloud footprint in our enterprise, which is the entire point of this product.
This ticket should NOT be a suggestion. This is a critical Bug as defined by your own policy https://confluence.atlassian.com/support/atlassian-cloud-bug-fix-policy-206865884.html as all three of the below requirements are true.
CCM