...
but as a part of this design work, we should come up with more concrete ideas for improvements and then create tickets for specific work that will tackle the performance issues mentioned above.
Known problem | Description | Improvements | ||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Entering the Physical Inventory screen fetches data for all of the programs | Just attempting to enter the Physical Inventory screen starts the fetch for all stock cards and a lot of other data for ALL of the available programs. This seems to be a waste of time and resources, if I'm only interested in one program. Details (measured in browser console): Get StockCardSummaries - 46.5s | |||||||||||||||
Executing StockCardSummariesv2 endpoint takes about 50 seconds for 20k FTAPs | Current performance of the StockCardSummariesV2 endpoint: For perftest: Profiler [FIND_STOCK_CARD_SUMMARIES_FOR_PARAMS] For uat: Profiler [FIND_STOCK_CARD_SUMMARIES_FOR_PARAMS] The full result can be found in result.csv (all times are given in seconds).
Additional info: Number of records on the perftest server: Number of records on the uat server: |
| ||||||||||||||
All the orderables for matching FTAPs are queried by id, just so they can be selected by name on product addition modal | We can look into a different strategy for retrieving orderable names - caching/limited representation/only allow retrieving them on search | |||||||||||||||
Can only query ~40 orderables by UUID at a time with GET request | The UI is querying for hundreds/thousands of orderables by IDs, and one request can only fit ~40 UUIDs. This means the UI is firing many requests to retrieve all of the data. If this is absolutely necessary to retrieve them, maybe other params could be used. | |||||||||||||||
Unnecessary call to /orderableFulfills | When entering the physical inventory screen, the UI sends a request to both StockCardSummaries and to OrderableFulfills. All the info retrieved by OrderableFulfills is already contained within StockCardSummaries (this endpoint also uses the Orderable Fulfills to build its response) and so, it shouldn't be required to query for it again. There's a chance that there's something missing in StockCardSummariesV2. | |||||||||||||||
StockCards must recalculate current SoH | Stock on Hand for the given StockCard is not stored anywhere. Each time the user is interested in the SoH (calling the summaries endpoint), the SoH must be recalculated, which is an expensive operation (it involves retrieving all the line items - aka stock movement, ordering them by date of occurence, and then going one by one to calculate the current stock on hand. The more stock movements, the more to calculate.
The options:
|
Next steps:
Problem | Solutions | Ticket | ||||||||
---|---|---|---|---|---|---|---|---|---|---|
StockCardSummariesV2 is slow | Start with improving the profiling for the endpoint - currently the profiler is added on the controller layer, but over 99% of the time the enpoint spends on the service/repository layer. |
|
...