Cornell reports that check-ins and checkouts range from 1 second to 5 seconds (and sometimes up to 11 seconds). Missouri State reports the same rate. We need to improve the processing time for check-ins and checkouts. This page is about the check out performance.
On https://wiki.folio.org/display/~marcjohnson/Check+Out+Performance Marc Johnson gives Context, Analysis, Options and Recommendations for check out performance. However, it is a private page.
The Capacity Planning Team has determined that we should proceed with the caching approach (with sequential execution of the non-cached requests).
Julian Ladisch suggests that this decision should be reversed and mod-circulation should be changed to run the requests in parallel.
This diagram is a preliminary analysis and shows which requests can most likely run in parallel – requests at the same vertical position run in parallel:
The red boxes are requests that cannot be avoided by caching: Fetching the item record by barcode, and using the itemId to fetch open loans and open requests for that item. They cannot be avoided by a cache maintained by mod-circulation because the cache most likely don't contain them.
Speeding up any other requests that run in parallel to these red requests doesn't give any performance advantage because the red requests are the bottleneck.
FOLIO selected Vert.x because it supports parallel requests – it has an easy to use concurrent and asynchronous programming model (promises, futures) without sacrifying correctness and performance. Okapi and many back-end modules use Vert.x. PostgreSQL is designed to handle multiple concurrent requests.