Bug 36239 - Availability calculation in OPAC Results XSLT is too slow
Summary: Availability calculation in OPAC Results XSLT is too slow
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Architecture, internals, and plumbing (show other bugs)
Version: Main
Hardware: All All
: P5 - low enhancement
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-03-06 01:55 UTC by David Cook
Modified: 2024-03-07 00:13 UTC (History)
0 users

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:
Circulation function:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description David Cook 2024-03-06 01:55:14 UTC
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...
Comment 1 David Cook 2024-03-06 02:22:43 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...
Comment 2 David Cook 2024-03-06 23:59:56 UTC
(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...