Performance Issue: GET API for order-lines is slow

Description

Overview:

This API as example: GET /orders/order-lines?limit=30&offset=0&query=%28%28contributors%3D%3D%22%2Atwitter%2A%22%20or%20poLineNumber%3D%3D%22%2Atwitter%2A%22%20or%20requester%3D%3D%22%2Atwitter%2A%22%20or%20titleOrPackage%3D%3D%22%2Atwitter%2A%22%20or%20publisher%3D%3D%22%2Atwitter%2A%22%20or%20vendorDetail.vendorAccount%3D%3D%22%2Atwitter%2A%22%20or%20vendorDetail.referenceNumbers%3D%3D%22%2Atwitter%2A%22%20or%20donor%3D%3D%22%2Atwitter%2A%22%20or%20selector%3D%3D%22%2Atwitter%2A%22%20or%20physical.volumes%3D%3D%22%2Atwitter%2A%22%20or%20details.productIds%3D%3D%22%2Atwitter%2A%22%29%29%20sortby%20metadata.updatedDate%2Fsort.descending

is taking significantly large amount of time between 7 to 17 secs for MI State

 

For Bugfest Juniper < 2s:

 

Steps for order-lines search workflow on bugfest-juniper:

  1. Log into some Bugfest Juniper.

  2. Open network tab to view API timings

  3. Click Orders - FOLIO (ebsco.com)

However this issue can't be observed on Bugfest Juniper. Just adding here to show the workflow.

Expected Results:

The mentioned API timings should be below 3 seconds at least.

Actual Results:

The mentioned API timings lies between 7 to 17 secs.

Additional Information:

  • This can be due to sheer amount of data that the tenant has on the table: po_lines in mod_orders_storage database.
    96534 order lines vs 25480 on bugfest.

  • We did not identify any slow queries in the database

  • Also checked the indexes. All indexes seems to be present on both places.

Interested parties:

CSP Request Details

None

CSP Rejection Details

None

Potential Workaround

None

Attachments

17
  • 13 Apr 2022, 09:19 PM
  • 13 Apr 2022, 09:17 PM
  • 13 Apr 2022, 01:08 PM
  • 13 Apr 2022, 01:08 PM
  • 13 Apr 2022, 01:08 PM
  • 13 Apr 2022, 10:55 AM
  • 13 Apr 2022, 10:55 AM
  • 13 Apr 2022, 10:54 AM
  • 13 Apr 2022, 10:05 AM
  • 13 Apr 2022, 10:05 AM
  • 13 Apr 2022, 09:03 AM
  • 13 Apr 2022, 08:21 AM

Checklist

hide

TestRail: Results

Activity

Show:

Damien April 13, 2022 at 9:35 PM

My PR optimizes keyword search, which I think was the subject of this story. I did not test other filters.

Dennis Bridges April 13, 2022 at 9:19 PM
Edited

From the ui it seems filtering can still be slower at roughly 9 seconds with 90,000 records. However, searching for specific details is returning results almost immediately. It seems performance has substantially improved though there may still be room for improvement in filtering.

Andrei Makaranka April 13, 2022 at 8:05 AM
Edited

Lotus result : Constantly search retrieves lines ~400ms from ~28000 lines on bugfest

Kiwi : Constantly search retrieves lines ~800ms from ~28000 lines on bugfest

Improvement x2

Constantly search retrieves lines ~1,3ms from ~38000 lines on Lotus bugfest. About 10000 meet search filter

Constantly search retrieves lines ~4,2 ms from ~68000 lines on Lotus bugfest. About 42000 meet search filter

Constantly search retrieves lines ~10 ms from ~93000 lines on Lotus bugfest. About 42000 meet search filter

As information was provided only about numbers of lines and no any info about lines which meet filter, than we can consider improvement was done

Earnings disappeared "WARNING: Doing LIKE search without index for" :

Oleksii Petrenko April 11, 2022 at 11:21 AM

Deployed to Lotus BF. Please proceed with verification

Andrei Makaranka April 8, 2022 at 12:11 PM

Fixed in scope of MODORDERS-661

Done

Details

Assignee

Reporter

Priority

Story Points

Sprint

Development Team

Thunderjet

Fix versions

Release

Lotus (R1 2022) Bug Fix

RCA Group

Data related (ex. Can be detected with large dataset only)

Affected Institution

MI State University/Library of Michigan

TestRail: Cases

Open TestRail: Cases

TestRail: Runs

Open TestRail: Runs
Created February 10, 2022 at 3:14 PM
Updated April 13, 2022 at 9:35 PM
Resolved April 8, 2022 at 12:11 PM
TestRail: Cases
TestRail: Runs

Flag notifications