DR-000027 - Check Out Performance

Owned by Radhakrishnan Gopalakrishnan
Last updated: May 06, 2024 by Jenn Colt
2 min read
Submitted Date

 
 

Approved Date


Status

DRAFT

ImpactMEDIUM

 

Overrides/Supersedes 

This decision was migrated from the Tech Leads Decision Log as part of a consolidation process.  The original decision record can be found here.

RFC 

N/A

Stakeholders

  • Technical Leads, Developers

Contributors

Julian Ladisch 

Approvers


Background/Context

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://folio-org.atlassian.net/wiki/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) with­out sac­ri­fy­ing cor­rect­ness and per­for­mance. Okapi and many back-end modules use Vert.x. PostgreSQL is designed to handle multiple concurrent requests.

Assumptions

N/A

Constraints

N/A

Rationale

Decision

Implications

  • Pros
    • N/A
  • Cons
    • N/A

Other Related Resources