Summary: | XSLT processing is much slower on OPAC than Staff Interface | ||
---|---|---|---|
Product: | Koha | Reporter: | David Cook <dcook> |
Component: | Searching | Assignee: | Bugs List <koha-bugs> |
Status: | CLOSED INVALID | QA Contact: | Testopia <testopia> |
Severity: | normal | ||
Priority: | P5 - low | ||
Version: | Main | ||
Hardware: | All | ||
OS: | All | ||
GIT URL: | 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-07 01:46:51 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... 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... |