Improve performance of logic around processing periods in requisition initiate

Description

One of the most time-consuming parts of the code in the requisition initiate endpoint is the part that retrieves and processes the periods. It seems that there are a couple of changes we can make there.

  • PeriodService.findPeriod seems to retrieve schedules to verify the period belongs to the schedule supported by a facility and program, but this logic seems to already be done on the reference data side (we retrieve processing period by facility and program)

  • PeriodService.findCurrentPeriodForInitiate retrieves a full representation of a requisition from the database in a loop - perhaps this can be improved somehow (getting rid of the loop, retrieving less data)

  • There's some logic that is dedicated for a case when initiate requisition is called with a suggested period - make sure this logic is only executed when suggested period was really provided

  • Probably more

ACC:

  • Before starting the work on this ticket, post profiler result for FIND_PROCESSING_PERIOD from the performance test server, document it here with the facility and program used (regular requisition, warm server, avg from 5 calls)

  • After the fixes, post the results of the profiler again (use same facility and program, regular requisition, avg from 5 calls)

 

Ideal world (platinum badge of performance awarded by Sebastian): the profiler reports avg<500ms
Good solution (golden badge of performance awarded by Sebastian): the profiler reports avg<1s
Not bad (silver badge of performance awarded by Sebastian): the profiler reports avg<2s

 

Pro tip: Want to better understand which part consumes most time? Add more profilers!

Assignee

Unassigned

Reporter

Sebastian Brudziński

Labels

Story Points

5

Epic Link

Components

Fix versions

Priority

Major
Configure