Metarecord summary can be very slow

[Mike Rylander]

 * 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...

[Mike Rylander (mrylander)]

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.

[Mike Rylander (mrylander)]

Branch available here:

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/miker/lp-2051708-big-MR-summary-is-slow

This includes a signoff of Jeff Davis's commit for bug #2039229.

[Galen Charlton (gmc)]

Tested and signed off; branch is user/gmcharlt/lp2051708_signoff

This one is a bit urgent for us, so I'll open another bug for further follow-up.

[Jason Boyer (jboyer)]

Pushed to main, rel_3_12, and rel_3_11. Thanks Mike and Galen!