poor performance viewing category retention schedule metadata (applied to record) with a lot of records in sub-folder(s)

Description

DESCRIPTION
When trying to 'View Details' of a retention schedule defined against a record category under the File Plan, it can take a long time to show the values if the schedule is applied to records, (not folders) and there are a lot of records in a folder(s) below that category.

REPRODUCTION STEPS

  1. Under the RM file plan, create a new category - 'testcat1'

  2. Under testcat1, create 2 more categories - 'testcat1_folder' and 'testcat1_record'

  3. create a retention schedule for both categories testcat1_folder and testcat1_record with an immediate cutoff action.

  4. The schedule must be applied to the folder level for testcat1_folder, and the record level for testcat1_record

  5. Create a target folder under each of the categories. 'folder_test1' and 'record_test1'

  6. create 15000 records in each folder

  7. Navigate to testcat1 in the file plan.

  8. enable network tracing in the browser tools

  9. Hover over testcat1_folder and click on Edit Details

  10. Hover over testcat1_record click on Edit Details

EXPECTED
The retention schedule properties should be returned in a similar amount of time

OBSERVED
Returning the result is noticably slower for testcat1_record compared to testcat1_folder.

ANALYSIS
These are calls being triggered by the reproduction steps

Tests showed the folder metadata came back in around 400ms on average. The record metadata returned in just under 20000ms

A further test created multiple folders under a record level category retention schedule and distribute records across the folders

  • 5 folders x 3000 records
    The request times were the same as the single folder with 15000 records

A yourkit snapshot from the customer showed these requests taking over 3 minutes to return. In that time, Share would time out and the request would fail.

There are a lot of SQL requests being made to the database for child associations. These perform well but we spend almost all the time processing the results.

The threads showing the behaviour are:

and

The snapshot will be uploaded to the FTP server.

Environment

None

Testcase ID

None

Activity

Show:
Cassandra Panayiotou
December 8, 2020, 2:30 PM

Just thought to share some great feedback after installing the hotfix:

I am happy to share some good news. The fix Alfresco provided has been deployed to the Dev environment and it works really great!

Opening the retention definition for the category that contains thousands of records (not as direct children) takes just a second or two.”

Thank you all so much

Cassandra Panayiotou
December 7, 2020, 7:57 PM

Thank you I will align with Indy later this week re. PaaS release version/timelines

Alexandru Epure
December 7, 2020, 3:00 PM

Big thanks to AGS 3.2.0.11 has been released (unfortunately the release script had a bug). artifacts can be found on:

volunteer to cherry pick the change to remaining branches.

Alexandru Epure
December 4, 2020, 3:54 PM
Edited

The PR containing the fix → has been accepted this morning, unfortunately the build has random failures (I`ve started it 7h ago).

Once the build is green I`ll merge the changes and trigger the GS 3.2.0.11 release, I`ll watch it over the weekend and the current expected target for the release is Monday morning.

Done

Assignee

Alexandru Epure

Reporter

Mark Tunmer

Labels

None

Security Issue

None

Escalated By

CSM

Hot Fix Version

AGS 3.2.0.11

ACT Numbers

01016956

Build Location

None

Regression Since

None

Premier Customer

None

Work Funnel End

None

Patch Attached

None

Dependent Version/s

None

Prioritization Score

None

Delivery Team

Customer Excellence

Bug Priority

Category 2

Components

Fix versions

Affects versions