Thanks guys! I have a bit of feedback on the process:

1. It would be great if we could link the development issues to the perf issues (looks like someone has done this now - thank you!)

2. It would be great if the person who filed a PERF issue (me in this case) could be tagged in the Interested parties section of the development issues that have been created

3. It would be great if the repro steps from the perf issue (this issue) would be replicated in the development issues (in this case, MODSOURCE-149 and MODSOURCE-150) so that it is clear that they are expected to resolve the issue described in the PERF

Tagging and as an FYI

Also the missing indexes warnings are covered by the story [CIRCSTORE-215]. More information you can find in the report https://folio-org.atlassian.net/wiki/pages/viewpage.action?pageId=1381682 in High Summary and recommendation sections

This performance report was created: https://folio-org.atlassian.net/wiki/pages/viewpage.action?pageId=1381682
The following JIRAs have been created for mod_source_record_storage to resolve the issue:

• MODSOURCE-149

• MODSOURCE-150

was there development done to resolve this issue? Or development tickets created? I don't see any linked here. Thanks!

High Level Summary

1. Slow APIs taking more than 100ms to run:

• GET source-storage/formattedRecords/id

• GET inventory/instances keyword all "aba"

• POST checkout-by-barcode

• GET inventory/items

• GET inventory/instances/{id}

• GET circulation/loans

• GET locations

• GET circulation/requests

1. Some mod_source_record_storage's, mod-inventory-storage's, mod-circulation-storage's SQL queries took more than 500 ms to run, see the Slow Queries section and Recommended Improvements for the JIRAs created to address these SQL queries

2. On average, the performance can be improved by 100%. if we remove redundant "EXPLAIN ANALYZE" query call on mod_source_record_storage module. EXPLAIN ANALYZE statements are debugging statements that added a second execution (along with the first one) therefore increasing the overall time by 100%.

3. JVM profiling shows the slowest operations, totaling more CPU time than other calls:

• Get module for request

• JSON de/serialization

• logging with INFO level