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.)
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...