There is a latency when placing a holding on a discovery service interface (EDS). Plan is to conduct analysis on placing holds algorithm/design

EDS layer calls mod-patron which in turn calls mod-circulation to place an instance-level request. The functionality to place instance-level requests is not native to mod-circulation, that is, mod-circulation was designed around placing item-level requests with request queues built on individual items. The mod-circulation instance-level request API, POST /circulation/requests/instances, works by 1) finding a list of available items of an instance, prioritizing them per business rules of status being Available, and if not Available, nearest location, and lastly by request queue sizes, 2) creating a list of requests: all combinations of request type (page, recall, hold) and item sorted by priority derived in #1, and finally loops through each of these request combinations attempting to place an item-level request until it successfully places a request. Due to this logic, the operation can be slow at time. The objective of this story is to investigate where the instance-level request is slow, in mod-circulation's native item-level request code, or mod-circulation's instance-level request code, or from mod-patron itself. mod-patron serves pretty much as a pass-through.

See https://folio-org.atlassian.net/browse/CIRC-245, https://folio-org.atlassian.net/browse/CIRC-264, https://folio-org.atlassian.net/browse/CIRC-265 for more information

Steps to Reproduce:
EDS programmatically calls mod-patron using the API - POST /patron/account/{id}/instance/{instanceId}/hold

An example of an instance-level request to mod-patron - feel free to swap out this instanceId with a different one that could stress the system more by having a long list of items.

mod-patron subsequently calls mod-circulation to place instance-level requests to POST /circulation/requests/instances

This is an "API" test, not a workflow test because we know specifically which APIs are called by the client. The JMeter script will simply have either one of these two calls, depending on if the test is designed to examine the workflow from mod-patron or from mod-circulation. It's uncertain calling which module directly would return a rich list of APIs with their response time data to carrier-io, whichever returns more data is the one that should be used.

Acceptance criteria:

• module logs will need to be examined for missing indexes warnings or any other anomalies.

• SQL logs will be examined for slow queries, those that take more than 20ms

• mod-inventory-storage, mod-circulation-storage, mod-circulation, mod-patron, and okapi will be profiled to find the bottlenecks.

• A report will created to document the findings.