-
Suggestion
-
Resolution: Unresolved
-
None
-
1
-
Problem
The Customer Portal can load fast for all Jira licenced users (Agents), but loads slowly for all Customers, when the number of customer portal is high
Environment
JSM 5.12.4
Steps to Reproduce
- Deploy a JSM 5.12.4 test instance.
- Create 1000 test service projects (each with a customer portal):
#!/bin/bash for i in $(seq 1 1000); do curl -X POST \ https://jira/rest/api/2/project \ -H 'Authorization: Bearer <token>' \ -H 'Content-Type: application/json' \ -d "{\"key\": \"ITSM${i}\",\"name\": \"ITSM Test ${i}\",\"projectTypeKey\": \"service_desk\",\"projectTemplateKey\": \"com.atlassian.servicedesk:itil-v2-service-desk-project\",\"description\": \"Example Project description\",\"lead\": \"admin\",\"assigneeType\": \"PROJECT_LEAD\",\"avatarId\": 10200}" done
Note that to speed up the scripted project creation it also helps to add an index to the fieldscreen table:
CREATE INDEX idx_name ON fieldscreen (name);
- Create a user without application access (i.e. a customer), log in with it and visit /servicedesk/customer/portals. Time how long it takes.
- Change customer permissions for all 1000 projects from Customers who have an account on this Jira site to Customers who are added to the project with the following SQL query:
UPDATE "AO_54307E_SERVICEDESK" SET "OPEN_CUSTOMER_ACCESS" = 0;
- Restart Jira.
- Visit /servicedesk/customer/portals again and time how long it takes.
Expected Results
There shouldn't be much difference between the customer accounts and licensed user accounts.
Actual Results
In HAR timing, the request rest/servicedesk/1/customer/models is much slower for customer accounts.
The delay seems to be due to Jira checking whether the user is a member of an organisation associated with the project, which is done once for each customer portal.
- links to
I've moved the ticket type from bug to feature request, as the underlying performance issue is caused by the feature which allows users to select a group/organisation for request filtering.
This feature is behaving as intended (hence not a bug), but was not designed to be scalable on 2000+ organisation and groups.