Details
-
Type:
Bug
-
Status: Closed (View Workflow)
-
Priority:
P2
-
Resolution: Done
-
Affects Version/s: None
-
Fix Version/s: None
-
Component/s: None
-
Template:customfield_11100 30099
-
Development Team:Core: Platform
Description
Steps to repro:
- Log into Chalmers environment OR Bugfest https://bugfest.folio.ebsco.com/ (ping me if you need login details)
- Find an item in inventory
- Check it into the check in app
- Takes 2 seconds
- Now add a request to that item
- Check it in again
Expected: Check in should take less than one second after any notes have been presented regardless of whether there are requests or not
Actual: Takes 4 seconds when there is a request on the checked in item. I added another request and the performance was still 4 seconds.
Additional info:
- While checking in an item that hasn't been requested is taking twice as long as it should (2 seconds instead of one) the focus of this issue should be the 4 seconds it takes when the checked in item is requested. We need to address this first.
- In some cases, some popups will display on the check in screen before the item has actually been checked in For example, if the item is a multipiece item or if there are check in notes. These popups are displaying really quickly and don't seem to be an issue. Also, they don't seem to be contributing much to the overall latency when checking in a requested item. If you measure the time passed after these popups are closed before the item is actually checked in, it still takes 4 seconds.
- 2019-09-19 Screencast showing bug in Bugfest environment: https://www.screencast.com/t/1zhK5C0b2oES
OLD RECORDINGS ------------------------------------------------------------------
- See this recording: https://drive.google.com/file/d/1wU_63Uv55z9MBIb10bMhk0n20pNPygXh/view relevant sections:
- 1:09
- 2:09
- Or this recording: https://drive.google.com/file/d/1Sbq4ZbOH50kh16wvwwSsKARsR5EOaRHk/view?usp=sharing
- 2:18
- I tested this later (just a few minutes ago), as Mark Veksler thought it might have been a temp issue related to an OKAPI restart, but the issue still repros. See this recording: https://drive.google.com/file/d/1KGnyoZ7CoDsauwgUt0QAn4Z6rBiDMiuK/view?usp=sharing
Additional info: The last recording shows that there are also performance issues saving a changed item record and saving a new request. I will create separate bugs for those.
NOTE: I tested this on Kristin Olofsson computer and it wasn't as slow, but it seems like it might get slower the more you do it.
Attachments
Issue Links
- clones
-
UICHKIN-111 Check in takes ~4 sec when item has request on it
-
- Closed
-
- is blocked by
-
CIRC-448 investigate and verify backend API performance issues for UICHKIN-111
-
- Closed
-
-
UICHKIN-112 do not block GET requests that participate in the check-in operation (possible partial solution for UICHKIN-111)
-
- Closed
-
- relates to
-
MODAT-49 Two caches for permissionsForUser and expandPermissions
-
- Closed
-
-
MODPERMS-66 Add indexes to improve performance
-
- Closed
-
-
MODPERMS-67 verify and reduce the cost of expanding permissions
-
- Closed
-
-
UICHKOUT-542 Check OUT takes 4 seconds (snapshot, Chalmers)
-
- Closed
-
-
MODNOTIFY-54 test /mod-notify/patron-notice API endpoint performance
-
- Closed
-