Metarecord summary can be very slow
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Evergreen |
Fix Released
|
High
|
Unassigned | ||
3.11 |
Fix Released
|
High
|
Unassigned |
Bug Description
* Evergreen version: 3.11+
As part of the angularization of the staff catalog, new logic was added to the bib summary API that gathers record attributes for the constituent records in a result's metarecord. For very large metarecords (~100+ constituents) this can be very slow, and when a search returns many bibs from the same metarecord, the underlying data is retrieved separately for each bib.
There are certainly some optimizations that could be applied to the MR summary calculation, but as an immediate measure, the MR summary should be cached within page-level API call so that each MR summary for a result page only needs to be calculated (and the 5+ second price paid) once per screen.
Branch coming soon...
Changed in evergreen: | |
importance: | Medium → High |
Changed in evergreen: | |
assignee: | Mike Rylander (mrylander) → Galen Charlton (gmc) |
milestone: | 3.11.3 → 3.12.1 |
Changed in evergreen: | |
assignee: | nobody → Jason Boyer (jboyer) |
Changed in evergreen: | |
status: | Fix Committed → Fix Released |
Since this directly addresses the same code touched by the proposed fix for bug #2039229, I will build the fix atop Jeff's branch from that bug.