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
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!