Speed up Requisition initiate back-end server time/load
Description
relates to
Confluence content
QAlity Plus - Test Management
Checklists
Activity
Moving to Done and tagging FixVersion=3.2.1.
Why? The work was all done in separate tickets, including those linked as well as https://openlmis.atlassian.net/browse/OLMIS-3322#icft=OLMIS-3322 and https://openlmis.atlassian.net/browse/OLMIS-3332#icft=OLMIS-3332 for release 3.2.1. This ticket itself does not have commits. But Done seems more appropriate than Dead, especially because there IS a linked review on this ticket. All of the linked OLMIS tickets are marked Done. Only 1 OLMIS ticket remains ToDo at this time (https://openlmis.atlassian.net/browse/OLMIS-2642#icft=OLMIS-2642).
Overall, in v3.2.1 there are major improvements to performance including Requisition Initiate performance. The Release Notes has a section called "Performance Improvements" that shows a chart and provides details: http://docs.openlmis.org/en/latest/releases/openlmis-ref-distro-v3.2.1.html
@Brandon Bowersox-Johnson It seems like we have done a bunch of work on this ticket – but as a part of other tickets
Can we mark this issue as dead?
@Paweł Albecki Okay, it sounds like it can stay as is for now.
Regarding "snapshotting Orderable", we talked about that some this morning at the Performance meeting: https://openlmis.atlassian.net/wiki/pages/viewpage.action?pageId=113988007 ... there will definitely be more tickets in future sprints for making sure the snapshot feature of Requisition is working correctly.
@Brandon Bowersox-Johnson Sorry for late answer! Yes, I kinda don't see a reason for retrieving full FTAP in a loop to just get orderableId. If we will make snapshot of availableNonFullSupplyProducts in Requsition Service, that would make a lot of sense but until we have decision about snapshotting Orderable (all required fields, not just Id) I think it can stay as it is for now.
@Paweł Albecki I didn't hear back from you about that previous question—you had mentioned a concern in your comment on 09/June. Is there any remaining issue?
@Paweł Gesek This ticket is not in our sprint, but we have merged in pull requests that address this ticket (the Malawi team has done a lot of work on their clone of this ticket). I would like to include this at Wednesday showcase. Please figure out how you'd like to do that (maybe okay to add this ticket into our sprint or maybe a special mention during Showcase of the Malawi issues)?
Details
Assignee
Reporter
Components
Fix versions
Priority
MajorTime Assistant
(split out from OLMIS-2533: Request payload too big for saving/retrieving requisitions and converting to orderDone per discussion in comments)
During the Malawi UAT, we discovered it takes over 60 seconds and over 1MB download to initiate a requisition (similar to submit, save, authorize, approve, and convert to order). Roughly half of this time (30 seconds) is server time preparing the response, and the other half is download time to download the 1MB (this half depends highly on your internet speed).
This particular ticket is about reducing the 30 seconds on the server processing, whereas the OLMIS-2533: Request payload too big for saving/retrieving requisitions and converting to orderDone ticket is about reducing the payload size to trim the download time.
Details
At the top of this list appears to be the need to reduce the number of calls that are needed to be made about Orderables to Reference Data.
Acceptance criteria:
an approach is defined for reducing the number of calls from Requisition Service to Reference Data service for details of the Orderable which are iteratively pulled every-time a Requisition DTO is built.
implement the approach
document the before and after so that we can see how many calls were reduced