Slow Responses for Media Object Edit Pages

[joncameron]

Description

Going through the edit steps for a media object can feel very slow, particularly when creating new items via the web interface, which is the common way to interact with item creation and editing for users. The requirement that each page is a step that must be navigated in a progression adds to this, especially since each page takes multiple seconds to return. This has been a common frustration for users adding new content.

Below are times reported by the network monitor in browser devtools in Firefox (avalon-dev) and Chrome (mco-staging) as a new item is created and "Save and continue" is selected to progress through the edit steps. Slower response times are expected on the development server, but the numbers from mco-staging show that this is across the board, and users in our production system wait for 17s+ for pages while creating a single item. Ideally this would be 1.5s or less for each page.

avalon-dev

Create new item (Manage Files): 7.84s Resource Description: 3.92s Structure: 10.78s Access Control: 6.08s Item Page: 1.92s

mco-staging

Create new item (Manage Files): 4.72s Resource Description: 3.01s Structure: 3.69s Access Control: 4s Item Page: 1.79s

Questions

• Is this just because of costly Fedora calls?
• Will Solr tuning help?
• Will other ongoing work (rethinking linked lists etc.) help with this, or are there other bottlenecks?

Done Looks Like

• [ ] Investigation/profiling of requests during processing and rendering of these pages

[elynema]

As of 6/11/24, avalon-dev timings seems somewhat better than this. Probably need to re-test this after 7.8 deployment to MCO? The move off of linked list may help a small amount, even for single section items.

Do we have documentation of past performance metrics? Past testing steps for many-sectioned items here: https://docs.google.com/spreadsheets/d/1sNI5W7WdFgkH9lTX41jxna_WfovM2Hsc/edit#gid=1316263048.

Perhaps we need to document a new benchmark.

[joncameron]

@joncameron will generate some new numbers and compare with expectations from previous. Should this be a priority in terms of performance improvements?

[masaball]

I'm not sure I used the exact same methodology as @joncameron, but starting from hitting "Create Item" on the manage collections page I got these timings on the network tab testing today:

mco-staging (2 runs, Chrome):

• create new item (manage files): 7s for both
• Resource description: 15s & 9s
• Structure: 5.5s & 11s
• Access control: 9.5s & 5s
• Item page: 6s & 8s

mco-staging (1 run, firefox):

• create new item (manage files): 6.63 s
• Resource description: 4s
• Structure: 5.5s
• Access Control: 5.4s
• Item Page: 7s

avalon-dev (2 runs, Firefox):

• create new item (manage files): 5.5s & 4s
• Resource description: 3s & 3.2s
• Structure: 10s & 3.29s
• Access control: 2.76s & 4.3s
• Item page: 4.5s & 4.5s (actual page load time seems closer to 2.5 seconds. I think the rest of the time in the network tab comes from Ramp finishing loading the media)

So timings are a bit all over the place for me, but at least in the ball park if not worse than they were last time benchmarking was done.

[elynema]

Work in prior releases on speeding up save focused on many-sectioned items. These tests were done when creating an item with a single section.

[elynema]

Jon and I agree that this data provides an initial benchmark for editing a single-section item, and we'd really like to improve these times.

It would be beneficial to do a full-application benchmarking project, but I'd want to edit the linked spreadsheet as it is focused only on many-sectioned items and processes on many items at a time. But we also want to know benchmarking for single items. I would like to make that a separate project potentially for the QA student.