Change the front end pagination to back end pagination in order to improve the performance

Description

Performance test report: https://docs.google.com/spreadsheets/d/1R9HcYBIAUki5KnM7pytRK3y4bdvhUEU8KvKuZLMosBA/edit#gid=0
Performance bottleneck: caused by SOH calculation
Performance benchmark
Potential solution: doing the pagination at the back-end
Potential solution:
modifying the search to directly search the database versus the client cache Client may be stressed because they wouldn't understand why they don't see all the products right away

Our design is loading all the data before user access to the event creation page
Take the adjustment as an example, it would cause 90 about 60 seconds loading time after user click the ‘create adjustment’ button next to a program. The data volume we used for the test is 1000 stock cards and each stock card has 300 stock line items.
Each request only gets 20 stock cards.
This would not cause the timeout but users need to wait for a while.
This solution might have an impact on the usability but considering the future offline function, loading the full data at once would be reasonable.

QAlity Plus - Test Management

Checklists

Activity

Wei Zhang 
May 25, 2017 at 4:56 PM


For this ticket has been done.
Attachment is the sheet of the performance data which is about before tuning and after tuning: https://docs.google.com/spreadsheets/d/1R9HcYBIAUki5KnM7pytRK3y4bdvhUEU8KvKuZLMosBA/edit#gid=2082254653

let us know if you have any feedback.

Shiyu Jin 
May 24, 2017 at 2:40 AM


This ticket is created to track the performance tuning.

Done
Pinned fields
Click on the next to a field label to start pinning.

Details

Assignee

Reporter

Sprint

Fix versions

Priority

Time Assistant

Created May 24, 2017 at 2:36 AM
Updated October 30, 2017 at 7:10 PM
Resolved May 25, 2017 at 11:33 PM