Performance (UXPROD-746)

[PERF-237] Investigating check-out and multiple loans renewal workflow performance improvement issues Created: 08/Mar/22  Updated: 10/May/23

Status: Open
Project: perf-testing
Components: None
Affects versions: None
Fix versions: None
Parent: Performance

Type: Story Priority: TBD
Reporter: Stephanie Buck Assignee: Stephanie Buck
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Relates
relates to PERF-242 Test Renewals for user with 2000 loans Open
relates to PERF-241 [Preparation] Script to add 2000 loan... Closed
relates to PERF-243 Test Create Loans for users with 2000... Closed
relates to PERF-221 Test automated patron blocks with lar... Open
relates to CIRC-1425 Check-out and multiple loans renewal ... Closed
Requires
is required by CIRC-1543 Check performance and scalability of ... Open
Sprint:
Development Team: PTF
Release: Quesnelia (R1 2024)
Epic Link: Performance
RCA Group: TBD

 Description   

Current situation or problem: Renewals and check-out performance suffers when a user has a lot of loans. A lot is ~1500+  loans 

In scope: Investigating causes of the performance issues, investigating ways to improve performance

Out of scope: 

Use case(s): The use case for a user with this many loans can be found in multiple libraries. Cornell, for example, has an interlibrary loan (ILL) users that have a lot of loans checked out at any given time and 21 ILL users

  • Max number of concurrent users

For these accounts with over 100 items on them, 3-4 users at a time. Cornell has ~20 desks, plus on-line renewal.

  • Number of ILL users with large amount of loans 

Cornell has 3-4 ILL accounts but have several patrons with more than 100 items out. As far as I know only the ILL accounts have 1,000+. I believe UChicago has stated that they have several users with 1,000+ items.

  • Max loans per user 

 2,500. Cornell has yet not started borrow direct and ILL is not up to full capacity so that number will definitely rise (from ~1500).

  • What else needs to happen in FOLIO at the same time? (i.e., data import)

Renewals are usually done during business hours so yes to everything. Data import, record maintenance, check-in check-out etc.

  • Expected amount of time for an ILL renewal to process

As quickly as possible. If I go by what it was in Voyager it would take about 15-20 seconds to renew all items if there were no blocks. If a quick turn around time was not possible having some sort of feedback would be helpful while items are being renewed.

Proposed solution/stories

Links to additional info: This originated  with CIRC-1425 and expanded to include CIRC-1434 and CIRC-1438

Questions



 Comments   
Comment by Stephanie Buck [ 11/Apr/22 ]

Thomas Trutt, can you add a screencast of the workflow? Thank you!

Comment by Martin Tran [ 02/Jun/22 ]

Stephanie Buck Does the workaround that was implemented in mod-patron-blocks (to address checking out slowness by a user that has thousands of loans) become permanent code or is it only a band aid awaiting a different solution? We should still have a test script for this scenario but I think the root cause of the problem is well understood. 

Comment by Stephanie Buck [ 02/Jun/22 ]

Hi Martin Tran. I don't think the workaround should become permanent code. It works, but it's a process. Thomas Trutt, do you agree? 

Comment by Khalilah Gambrell [ 14/Jul/22 ]

Hey Stephanie Buck - should this move to Nolana?

Comment by Stephanie Buck [ 21/Sep/22 ]

Martin Tran, if this relates to https://folio-org.atlassian.net/browse/PERF-242, should we close this ticket out?

Comment by Khalilah Gambrell [ 09/May/23 ]

Hey Martin Tran - what should we do with this ticket?

Comment by Martin Tran [ 10/May/23 ]

Khalilah Gambrell  Unfortunately we don't have time to work on this story right now, but will pick it up when we have time or if Stephanie Buck  and you think that it's very crucial to test/investigate performance of this use case.

Generated at Fri Feb 09 00:33:15 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.