Page tree
Skip to end of metadata
Go to start of metadata

UXPROD-2364 - Getting issue details... STATUS

Problem:

The current order search and filter performance is slow. In Bugfest environments with a substantial number of order records users can wait up to 10 - 15 seconds for search results to display in the UI.

Performance target:

  • How many users at any given time: Uncertain that this has an impact as there would not have been more than 20-30 users in the Q1 bugfest environment
  • Volume of data; 15k order records, 15k+ order lines, 7k organizations, 15k+ inventory records
  • Expected response time: 2 seconds

Investigation:

  • Review by performance team see  PERF-84 - Getting issue details... STATUS . Findings suggest some improvements that could be made to queries.
    • It doesn't seem this will make a substantial impact on performance but could be a quick improvement
  • Suggested architectural update is to change from views to cross-index subqueries  MODORDSTOR-210 - Getting issue details... STATUS
    • Would this make a substantial impact on performance? NOTE Performance testing team (Martin Tran) suggested that if we put a simple POC together they would be able to run performance testing with it.
  • A POC for Elasticsearch is in progress and first implementation will be done with the inventory app in R1  UXPROD-2807 - Getting issue details... STATUS
    • Would performance of elasticsearch be superior to the existing orders search?
    • Would it make more sense to implement elastic search than work on enhancements for the current order search?

Questions:


Decisions & Logic


  • No labels

1 Comment

  1. Use case from Chicago:

    Users have found that with so many orders in the system. Every time a user returns to the orders app the search seems to be completely re-run. This cannot be interrupted and can take quite a long time to finish. Meaning the user needs to wait for it to finish to run their next search or make an edit to the record they were looking at. Because of this the search is actually slowing down workflows that don't even include a search.