[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: |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 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 |