[Bug 36239] New: Availability calculation in OPAC Results XSLT is too slow
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36239 Bug ID: 36239 Summary: Availability calculation in OPAC Results XSLT is too slow Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs@lists.koha-community.org Reporter: dcook@prosentient.com.au QA Contact: testopia@bugs.koha-community.org buildKohaItemsNamespace is really slow in XSLTParse4Display when there is a record with a large number of items. On one system, we notice a search on the staff interface is 12 seconds whereas it's 1-2 minutes in the OPAC. I'm slowly tweaking things to improve the speed, but one of the big killers is buildKohaItemsNamespace. I think there are many use cases for having a Real Time Availability API endpoint, and this would be one of them. We could have a little loading CSS-driven graphic, send a list of biblionumbers to the endpoint asynchronously, and then render the availability. If we handle the availability through that endpoint (or at least a singular model method), we should be able to make further optimizations to availability calculation as well... -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36239 --- Comment #1 from David Cook <dcook@prosentient.com.au> --- 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... -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36239 --- Comment #2 from David Cook <dcook@prosentient.com.au> --- (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... -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36239 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=36261 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org