Summary: | Availability calculation in OPAC Results XSLT is too slow | ||
---|---|---|---|
Product: | Koha | Reporter: | David Cook <dcook> |
Component: | Architecture, internals, and plumbing | Assignee: | Bugs List <koha-bugs> |
Status: | NEW --- | QA Contact: | Testopia <testopia> |
Severity: | enhancement | ||
Priority: | P5 - low | ||
Version: | Main | ||
Hardware: | All | ||
OS: | All | ||
See Also: | https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36261 | ||
Change sponsored?: | --- | Patch complexity: | --- |
Documentation contact: | Documentation submission: | ||
Text to go in the release notes: | Version(s) released in: | ||
Circulation function: |
Description
David Cook
2024-03-06 01:55:14 UTC
That said, when I actually break it down a bit more, it looks like out of 60 seconds for my example, 20 seconds are availability and 40 seconds is the rest. If it's 10 seconds in the staff interface, then it's probably 30 seconds on OpacHiddenItems which happens before buildKohaItemsNamespace. That's an overgeneralization of course. But if we got rid of OpacHiddenItemsHidesRecord and required people to use OpacSuppression instead then we'd be able to bring OPAC and Staff Interface back to similar times... (In reply to David Cook from comment #1) > That said, when I actually break it down a bit more, it looks like out of 60 > seconds for my example, 20 seconds are availability and 40 seconds is the > rest. If it's 10 seconds in the staff interface, then it's probably 30 > seconds on OpacHiddenItems which happens before buildKohaItemsNamespace. > > That's an overgeneralization of course. > > But if we got rid of OpacHiddenItemsHidesRecord and required people to use > OpacSuppression instead then we'd be able to bring OPAC and Staff Interface > back to similar times... It looks like I was at least partially wrong... With no change, my search is actually taking 66 seconds, and if I completely remove OpacHiddenItems, I only gain 11-12 seconds. In good news, I've written an optimization for OpacHiddenItems, which effectively eliminates the overhead of running it. So yippee! I'll open a different ticket for that. But I was hoping to save more like 30 seconds. So it seems like there's still more optimizing to do on other parts of OPAC search. It seems like there still 20 seconds unaccounted for in my search... |