Performance question...
I have a performance problem which I'm probably causing myself. The search takes forever and as you can see below, my approach can surely be optimized. However I don't see how. Can you help?
---------------------------------------------------
My search results tag looks like this:
{exp:low_search:results query="{segment_3}" channel="web|utbildningar|static" loose_ends="both" orderby="section" sort="asc" disable="categories|category_fields|member_data|pagination"}
<!--- I put all my results in a Stash list here --->
{/exp:low_search:results}
---------------------------------------------------
In my test, the search takes a total of about 7 seconds and the Low Search module accounts for about 4-5 seconds of that total. The template debugger knows what's going:
(0.826924 / 2.33MB) Calling Extension Class/Method: Low_reorder_ext/low_search_post_search
(0.827170 / 2.33MB) Low Search: Parameters set: query="eyJyZXN1bHRfcGFnZSI6InNvayIsImtleXdvcmRzIjoic3RhdGlzdGlrIGF2dGFsIn0" channel="web|utbildningar|static" loose_ends="both" orderby="section" sort="asc" disable="categories|category_fields|member_data|pagination" result_page="sok" keywords="statistik avtal" search_mode="any" entry_id="1|3|23|28|29|30|32|33|35|36|37|39|41|42|43|44|45|46|47|49|51|54|55|56|58|60|61|65|66|68|70|72|73|75|79|80|81|82|83|84|86|88|89|90|92|94|95|96|99|100|101|103|106|107|108|109|113|114|116|117|118|119|121|122|124|126|128|129|130|133|134|135|136|139|140|141|145|146|150|152|153|154|155|156|157|158|162|163|164|166|167|169|172|174|176|179|180|182|183|184|185|186|189|190|192|193|195|196|197|198|199|201|206|208|209|210|211|212|213|214|215|216|219|221|225|228|230|232|233|234|235|237|238|239|240|241|242|243|244|245|247|248|249|253|255|256|257|259|262|263|264|265|266|267|270|271|273|275|277|279|281|283|285|286|292|293|294|295|296|297|299|301|302|304|324|312|315|316|317|318|5|308|311|415|321|323|327|328|329|331|333|334|335|336|338|340|341|342|343|345|346|349|350|353|354|361|377|378|380|383|447|405|406|408|410|412|413|414|352"
(0.827181 / 2.32MB) Low Search: Pre-applying search vars to tagdata
(0.846953 / 2.35MB) Low Search: Calling the channel module
(0.899866 / 5.11MB) Calling Extension Class/Method: Low_reorder_ext/channel_entries_query_result
(0.900335 / 5.12MB) Calling Extension Class/Method: Low_search_ext/channel_entries_query_result
(2.741340 / 8.71MB) Calling Extension Class/Method: Low_search_ext/custom_field_modify_data
(.................) Approximately 1400 debugger rows deleted
(5.295988 / 9.19MB) Calling Extension Class/Method: Low_search_ext/custom_field_modify_data
(5.311688 / 3.51MB) -> Data Returned
Replies
Low 28 Jan 2015 12:51
First of all, I'd recommend not using loose_ends="both" unless the language doesn't do spaces for word separators. Set it to "right" or even "none" to make use of MySQL's fulltext capabilities, which will speed up queries.
I'd also recommend setting the collection="" parameter explicitly. It will internally set a channel_id parameter based on the collections, which would speed up some queries as well.
Furthermore, the big issue seems to be more when calling the extension result data, not necessarily the query itself (although I cannot tell how long that takes since that's missing from the debug data). That's probably because a large amount of search results are displayed, because there is no limit="" defined. That will default to 100 entries. Try setting the limit to, say, 25 entries and use pagination. That should speed things up as well.
Matts Härsing 28 Jan 2015 13:49
Thanks, I'll try your suggestions. Although I found that when using loose_ends="right/none", a lot of entries were not being displayed that contained legitimate words that should have been picked up by the search engine.
As for the limit, this would be a problem as I am splitting up my results into sections. This would mean that, with a limit of 50 results, a section that returns 50 or more results would cause the other sections to seem to return 0 hits.
For example:
Newsletters (50 hits):
1. yada
2. yada
...
50. yada
Some other section (0 hits)
Yet another section (0 hits)
Low 28 Jan 2015 14:06
Re: pagination; yes, that's the effect that will have. You might have to test out which method is best for performance.
Re: loose_ends; this depends on what you consider "legitimate words". Using loose_ends="both" is basically a substring search, matching "lion" to "millionaire", which wouldn't be a relevant search term, really.
Just think you would search in google. I doubt very much you use substrings for searching, there. Rather, you use full words, or start typing a full word, making loose_ends="none/right" a much better fit.
Matts Härsing 28 Jan 2015 14:10
I tried your suggestions and it works pretty well. It seems to spread the hits out over all the collections used in the results tag, which is great.
Thanks.