Comment 8 for bug 1704396
Revision history for this message
| Kathy Lussier (klussier) wrote Re: Slowness for metecord and one-hit searches in 2.12 | #8 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
1b1ed1a
(Get the code!)
I had previously only been able to replicate the MR search problem on multiple servers. To ensure that the one-hit search problem wasn't the result of a customization, I looked a little more deeply at the problem and was able to replicate it on the C/W MARS training server, which is running 2.12.3. C/W MARS has also enabled the setting to automatically redirect to the record on one-hit searches.
I don't have access to the logs, but I wanted to note down a few observations from my testing:
1. I ran about 100 one-hit ISBN searches in the C/W MARS catalog. Ten of those searches showed the 70-second delay. Another search resulted in an Internal Server error. The percentage may seem low, but when you consider the amount of ISBN searches a cataloger does throughout the day, they are likely to encounter several of these slow searches every day.
2. In most cases, the delay only happened when I performed the first search on the ISBN. Subsequent searches were fine, including the ISBN search that had previously resulted in an Internal Server error. However, two of the ISBN searches continued to show the 70-second lag in repeated searches, eventually showing normal retrieval times after 4-5 tries.
3. After the delay, the bib record is retrieved as expected (except in the case of the Internal Server error). I performed a diff on the HTML generated from the record page after two identical ISBN searches (one that experienced the lag and the other that didn't), but there were no differences. This is different from my experience with the MR search, where searches with a 70-second lag resulted in one of the links missing a record ID.
4. The one-hit redirect setting doesn't always work. We sometimes land on the results page when there is only one result (I think this has always been true.) There were a couple of cases where I performed an ISBN search and landed on the results page very quickly even though there was just one hit. I then re-executed that search in an attempt to get it to land on the record page and saw the 70-second lag. This makes me think that the problem isn't with the search query, but with attempt to load the record on redirect.