[UXPROD-4539] FQM/Lists: Improve performance Created: 01/Nov/23  Updated: 07/Feb/24

Status: In Progress
Project: UX Product
Components: None
Affects versions: None
Fix versions: Quesnelia (R1 2024)

Type: New Feature Priority: P2
Reporter: Matt Weaver Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Continues
is continued by UXPROD-4690 FQM/Lists: Improve performance - pt. 2 Draft
Defines
defines MODLISTS-58 Compile a list of queries for PTF to ... Closed
defines MODFQMMGR-61 Rework derived views to use indexes f... Closed
defines MODFQMMGR-63 Rework derived views to use indexes f... Closed
defines MODFQMMGR-64 Rework derived views to use indexes f... Closed
defines MODFQMMGR-65 Rework derived views to use indexes f... Closed
defines MODFQMMGR-74 SPIKE: Investigate refactoring views ... Closed
defines MODFQMMGR-79 Add searchable field support Closed
defines MODFQMMGR-81 Refactor how we do case-insensitive s... Closed
is defined by PERF-766 ListApp failed on updating long durat... Open
is defined by MODFQMMGR-98 Add filter value getters for the Item... Closed
is defined by MODFQMMGR-109 Add filter value getters for the User... Closed
is defined by MODFQMMGR-110 Add filter value getters for the Loan... Closed
is defined by MODFQMMGR-102 Swap the components in the mod_fqm_ma... Closed
is defined by MODFQMMGR-62 Rework derived views to use indexes f... Closed
Potential Workaround: Queries that make use of indexed fields are significantly faster. Often, narrowing a query with additional filtering on different fields to take advantage of this can make a huge difference (e.g., filtering on creation dates or loan status in cases when the desired list is fairly homogenous, even when the date or status wouldn't otherwise be relevant).
Release: Quesnelia (R1 2024)
Development Team: Corsair
PO Rank: 0

 Description   

Current situation or problem: A lot of FQM queries are very slow (>10 minutes). We need to improve this, as this greatly impacts the user experience in the Lists app, frustrating users and reducing the app's utility quite a bit.

In scope: DB query performance, suboptimal API interactions, project architecture. Specifically, we want to improve the performance of FQL query execution and reduce the overhead involved with mod-lists's interactions with FQM. The performance is most visible when running test queries and refreshing lists in mod-lists. The goal for overhead is to reduce the cross-app interaction overhead to less than 5% of the overall list refresh time. The overall performance goal is for simple lists (especially the canned lists) to refresh consistently in less than 3 minutes. We can measure these by looking at the list refresh performance metadata in the DB, which provides a breakdown of how long each phase takes.

Out of scope: Overhead within other apps (i.e., things in other apps, outside the API access pattern)

Use case(s)

Proposed solution/stories

Links to additional info

Questions


Generated at Fri Feb 09 00:40:41 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.