Comment 10 for bug 1704396
Revision history for this message
| Mike Rylander (mrylander) wrote Re: Slowness for metecord and one-hit searches in 2.12 | #10 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
1b1ed1a
(Get the code!)
To provide a little analysis based on comment #8:
(3) suggests that the search (in all circumstances) is succeeding, because a fast return on subsequent requests means that the search is most likely cached as expected.
(4) further lends weight to the idea that it's the record detail page rendering that is the actual issue here. The fact that it only happens when the user is bounced past the result page and redirected to the detail page pretty much rules out the actual search process.
Do we have any indication that record detail pages generally are having issues, or have there /only/ been reports of 1-hit auto-redirects causing this pause behavior?
Now with more activity log traces that document the problem in real-time, it looks like the peer-bib check I noted above is a red herring. Two of the pauses happened after all those calls, which is more than 25% of the accumulated timelog evidence.
I think it's time to start looking at the opensrf system logs in detail...