Bug 36264 - XSLT processing is much slower on OPAC than Staff Interface
Summary: XSLT processing is much slower on OPAC than Staff Interface
Status: RESOLVED INVALID
Alias: None
Product: Koha
Classification: Unclassified
Component: Searching (show other bugs)
Version: Main
Hardware: All All
: P5 - low normal (vote)
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-03-07 01:46 UTC by David Cook
Modified: 2024-03-07 02:23 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:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description David Cook 2024-03-07 01:46:51 UTC
I haven't figured this one out yet, but it looks like the XSLT processing for search results is much slower on the OPAC than on the Staff Interface.

No XSLT (disabled in code):
OPAC: 18.69 seconds
Staff: 10.5 seconds

Default XSLT:
OPAC: 25.7 seconds
Staff: 10.6 seconds

As you can see here, the XSLT processing for the staff interface is much faster. Iā€™d say the OPAC takes 7 seconds whereas the Staff takes .1 seconds. This is certainly worth reviewing.

(Note I'm using Zebra but it should be irrelevant for this testing. The same problem should exist for both Zebra and Elasticsearch...)

(Note also that it's clearly not the only discrepancy between the two search interfaces. Note that OpacHiddenItems isn't contributing to the slowness on the OPAC side.)
Comment 1 David Cook 2024-03-07 02:08:32 UTC
Using "strace", I've been analyzing the searches, and comparing the staff interface versus the OPAC.

They both take 1-2 seconds to get started up, and then they lose roughly the same amount of time getting Zebra facets (in my cease about 9-12 seconds). 

It takes about 1 second to process the 20 records in the staff interface, but it takes about 16 seconds to process the 20 records for the OPAC. 

The last 2 seconds of the OPAC are dedicated to template render. The staff interface spends 4 seconds on its final steps. Some of this is template render and some is work that I haven't analyzed yet, but I'm not worried about at this stage.

Used PassItemMarcToXSLT and removed buildKohaItemsNamespace, and I'm getting:

Default XSLT:
OPAC: 19.21 seconds
Staff: 11 seconds

No XSLT (disabled in code):
OPAC: 19.62
Staff: 10.7

The main difference here is the PassItemMarcToXSLT, so that's interesting... sounds like items are having an impact on the OPAC XSLT processing even if buildKohaItemsNamespace isn't being used...
Comment 2 David Cook 2024-03-07 02:23:42 UTC
Nevermind... I was comparing apples and oranges.

OPAC defaults to relevance sort whereas the Staff Interface doesn't, so I was getting different results which were processed at different rates.

With both using relevance sorting, I'm getting the same processing times between the two interfaces.

Yay... now they're both equally as slow...