Avoid Internal Server Errors with Hold Count Calculation/Display

Bug #1155706 reported by Kyle Tomita on 2013-03-15
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Evergreen
Medium
Unassigned
3.0
Medium
Unassigned
3.1
Medium
Unassigned
3.2
Undecided
Unassigned

Bug Description

This issue arose because of Internal Server errors caused by time out of loading search results on our system, which displays the hold count for each record. Before the count is displayed, it is calculated on load, causing the issue.

The approach to address this is to precalculate the hold count and store it in a new table. The count would be updated on the creation, fulfillment, or cancellation of a hold. This moves the processing time away from the returning of search results, which is used a lot more than modifying holds.

On our system, we have seen speed increases on the returning of search results. Currently, our implementation only focuses a few hold types, since we only use a few. This fix will be ported over to master and updated with a larger set of hold types for community.

Thomas Berezansky (tsbere) wrote :

As a general note on this: I am working on some improvements for search that would likely include open hold counts as one of a number of things to be stored in an additional table. Some of it is still in the planning phases, granted (see some of the activity metric discussion on the general list). I imagine that my broader scope work will conflict with this work, if not in original intent than in duplication of work that the backend is doing.

If you want to question me about what I am working on feel free to email me.

Ben Shum (bshum) on 2013-03-17
Changed in evergreen:
milestone: 2.4.0-beta → 2.4.0-rc
Ben Shum (bshum) on 2013-03-17
Changed in evergreen:
importance: Undecided → Wishlist
status: New → Triaged
Kyle Tomita (tomitakyle) wrote :

I look forward to seeing your search improvements.

Ben Shum (bshum) on 2013-04-22
Changed in evergreen:
milestone: 2.4.0-rc → 2.5.0-alpha
Dan Wells (dbw2) on 2013-06-13
Changed in evergreen:
milestone: 2.5.0-m1 → none

The work that Thomas Berezansky (tsbere) mentioned back in 2013 was completed, but then it was removed when other new development broke its functionality. So if someone still wants to work on this issue, don't worry about conflicting with what tsbere was working on.

Josh

Jane Sandberg (sandbej) on 2018-05-20
tags: added: holds performance
removed: count hold
Changed in evergreen:
status: Triaged → Confirmed
importance: Wishlist → Medium
assignee: Kyle Tomita (tomitakyle) → nobody
milestone: none → 3.2-beta
Jason Stephenson (jstephenson) wrote :

This is a bug! Internal Server Errors are not a feature!

I don't have a fix for performance, but I can make the ISRs go away.

I also don't think Kyle is still working on this after 5 years, and there have been even more changes to the code in the mean time, so I think the performance aspect of this is mostly obsolete.

summary: - Speed Up Hold Count Calculation/Display
+ Avoid Internal Server Errors with Hold Count Calculation/Display
Jason Stephenson (jstephenson) wrote :

Branch pushed to working/user/dyrcona/lp1155706-avoid-internal-server-errors

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/dyrcona/lp1155706-avoid-internal-server-errors

I've been able to go through man results record by record with no internal server errors, even on a cold server.

tags: added: pullrequest
Changed in evergreen:
milestone: 3.2-beta → 3.2-rc
Changed in evergreen:
milestone: 3.2-rc → 3.2.1
Changed in evergreen:
milestone: 3.2.1 → 3.2.2
Changed in evergreen:
milestone: 3.2.2 → 3.2.3
Changed in evergreen:
milestone: 3.2.3 → 3.3-beta1
status: Confirmed → New
Changed in evergreen:
milestone: 3.3-beta1 → 3.3-rc
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers