User reported Collection Management interface loads very slowly for all collections, no matter the size.
User provided deployment details report, which indicates operationId getCollection is taking an average of 28 seconds when the labels and grants projections are included (these projections are included in the request when the Collection Management UI is loaded) . Overall, average duration of .450 seconds overall for this opId. It may be relevant that the user makes heavy use of the Labels feature.
Call to getCollectionLabels always asks for "all" labels, even if queryCollections received a collectionId param. (later, only the labels for the relevant collectionId are attached to the returned collectionResults)
OpId is much more performant when those lines are changed to:
if (inProjection.includes('labels')) {
if ( inPredicates.collectionId ) {
queries.push(_this.getCollectionLabels(inPredicates.collectionId, userObject))
}
else {
queries.push(_this.getCollectionLabels('all', userObject))
}
}
Haven't recreated the drastic performance issue related to the user story, but with test data found this change to cut processing time in half.
User reported Collection Management interface loads very slowly for all collections, no matter the size. User provided deployment details report, which indicates operationId getCollection is taking an average of 28 seconds when the labels and grants projections are included (these projections are included in the request when the Collection Management UI is loaded) . Overall, average duration of .450 seconds overall for this opId. It may be relevant that the user makes heavy use of the Labels feature.
Suspect the issue is here: https://github.com/NUWCDIVNPT/stig-manager/blob/99199962ed51d8967ecf543101059c486734b417/api/source/service/CollectionService.js#L108-L110
Call to getCollectionLabels always asks for "all" labels, even if queryCollections received a collectionId param. (later, only the labels for the relevant collectionId are attached to the returned collectionResults) OpId is much more performant when those lines are changed to:
Haven't recreated the drastic performance issue related to the user story, but with test data found this change to cut processing time in half.
issue-stig-manager-details_2024-09-03T1912Z.json