This issue was originally reported in bug 14320. If the AllowRenewalIfOtherItemsAvailable sys pref is set to allow, and a borrower has an item checked out that has many items {30+} AND many holds {70+) on it, loading the checkouts table for this borrower takes FOREVER to load. The load time takes forever, because of the factoring that happens to determine if an item is truly available for renewal. At this time, the situation couldn't be improved in bug 14320, but I want this report out there, in case this becomes a bigger problem and/or someone comes up with a way to speed up the processing.
Created attachment 54813 [details] [review] Bug 14736 - AllowRenewalIfOtherItemsAvailable slows circulation down in case of a record with many items and many holds If the AllowRenewalIfOtherItemsAvailable sys pref is set to allow, and a borrower has an item checked out that has many items {30+} AND many holds {70+) on it, loading the checkouts table for this borrower takes FOREVER to load. The load time takes forever, because of the factoring that happens to determine if an item is truly available for renewal. This patch swaps the use of GetMemberDetails for GetMember and reorders the subroutine calls to check each items' renewability from fastest to slowest. In a test case, the results of pre patch were: Start of loop: 2016-08-24T11:05:14 End of loop: 2016-08-24T11:05:29 Resulting in 15 seconds being spent in the loop Post patch results were: Start of loop: 2016-08-24T11:08:43 End of loop: 2016-08-24T11:08:48 Resulting in only 5 seconds being spent in the loop! Test Plan: 1) Apply this patch 2) Note there are no changes in functionality for the renewals column of the patron checkouts table. If you wish to go further and test the performance benefit: 1) Create a record with 50 items and 100 holds ( 50 waiting, 50 unfilled ) 2) Check out one of the waiting holds to a patron 3) Time the amount of time it takes for the checkouts table to load 4) Apply this patch 5) Repeat step 3, you should see an improvement in load time
Created attachment 56463 [details] [review] Bug 14736 - AllowRenewalIfOtherItemsAvailable slows circulation down in case of a record with many items and many holds If the AllowRenewalIfOtherItemsAvailable sys pref is set to allow, and a borrower has an item checked out that has many items {30+} AND many holds {70+) on it, loading the checkouts table for this borrower takes FOREVER to load. The load time takes forever, because of the factoring that happens to determine if an item is truly available for renewal. This patch swaps the use of GetMemberDetails for GetMember and reorders the subroutine calls to check each items' renewability from fastest to slowest. In a test case, the results of pre patch were: Start of loop: 2016-08-24T11:05:14 End of loop: 2016-08-24T11:05:29 Resulting in 15 seconds being spent in the loop Post patch results were: Start of loop: 2016-08-24T11:08:43 End of loop: 2016-08-24T11:08:48 Resulting in only 5 seconds being spent in the loop! Test Plan: 1) Apply this patch 2) Note there are no changes in functionality for the renewals column of the patron checkouts table. If you wish to go further and test the performance benefit: 1) Create a record with 50 items and 100 holds ( 50 waiting, 50 unfilled ) 2) Check out one of the waiting holds to a patron 3) Time the amount of time it takes for the checkouts table to load 4) Apply this patch 5) Repeat step 3, you should see an improvement in load time Signed-off-by: Jesse Maseto <jesse@bywatersolutions.com>
Created attachment 57636 [details] [review] Bug 14736 - AllowRenewalIfOtherItemsAvailable slows circulation down in case of a record with many items and many holds If the AllowRenewalIfOtherItemsAvailable sys pref is set to allow, and a borrower has an item checked out that has many items {30+} AND many holds {70+) on it, loading the checkouts table for this borrower takes FOREVER to load. The load time takes forever, because of the factoring that happens to determine if an item is truly available for renewal. This patch swaps the use of GetMemberDetails for GetMember and reorders the subroutine calls to check each items' renewability from fastest to slowest. In a test case, the results of pre patch were: Start of loop: 2016-08-24T11:05:14 End of loop: 2016-08-24T11:05:29 Resulting in 15 seconds being spent in the loop Post patch results were: Start of loop: 2016-08-24T11:08:43 End of loop: 2016-08-24T11:08:48 Resulting in only 5 seconds being spent in the loop! Test Plan: 1) Apply this patch 2) Note there are no changes in functionality for the renewals column of the patron checkouts table. If you wish to go further and test the performance benefit: 1) Create a record with 50 items and 100 holds ( 50 waiting, 50 unfilled ) 2) Check out one of the waiting holds to a patron 3) Time the amount of time it takes for the checkouts table to load 4) Apply this patch 5) Repeat step 3, you should see an improvement in load time Signed-off-by: Jesse Maseto <jesse@bywatersolutions.com> Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Great catch Kyle!
Pushed to master for 16.11!
Pushed to 3.22.x, will be in 3.22.13
Pushed to 16.05.x, for 16.05.06 release