Search is very slow

CMS > Content Modules
1

I just did a test to implement site search on a mostly empty trialsite and site search was very very slow. I had a 76s TCP response and 194s onload event.

Are others experiencing this? Do you have workarounds? Could it be an implementation issue? I just inserted the default search form on an empty page and there are probably only 20 items total across all modules/pages/forms on this test site.

I also noticed that on the Docs demo site search was very slow. In the range of 30s for search results.

2

Docs Demo site seems to be fine now, perhaps was a temporary issue?
But one thing to make sure is that your search results page is marked as ā€˜Disable From Site Searchā€™ otherwise you can get a recursion issue if it includes itself in the results.

1 Like
3

Hi @Alex_B_Centrifuge, We will check it on your site. I will come back to you once I have any updates.

4

Still takes about 35 seconds for the docs demo site to return a search result.

(also docs site is SLOWWWWW to load)

@Irene Thanks for looking into this.

5

Am I the only one experiencing this? Are others using search successfully?

6

Hey @Alex_B_Centrifuge.
The Docs site is slow overall, yes. This is being worked on.
However, site search in general Iā€™m not experiencing any slow loading for (on various other sites).
Are you still seeing slow results on the Docs Demo Site?
Are you seeing slow search results on any of your sites?

1 Like
7

I can tell you that having this in a component searchScope: "{\"prop_parentId\":\"2221\",\"prop_ItemCategories\":[\"Events\"]}",

Kills page load timesā€¦ I am currently going through a fresh migration. Iā€™ve converted these calls back to standard filters as that above code affects page speed big time.

Also side note. The app did not migrate categories against the items so the above doesnā€™t show anything at all lol!
Still takes ages to load the page.

Affected both on liquid 1 and 2.

1 Like
8

Iā€™m not sure if these things relate to either your @James or @Alex_B_Centrifuge implementation, but 2 things to check with search that Iā€™ve see is:

  1. ensure the search results page is excluded from search (else a recursion can occur)
  2. ensure the items layout you are using to display search results doesnā€™t contain the description field (else strange things can occur due to additional page content/liquid rendering)
1 Like
9

Hey @Adam.Wilson, yes the docs site search is very slow for me still. I just did a search and it took a while to return a result (16s).

I donā€™t have search on any live sites yet, but I will have to as I get ready to migrate over/build ecomm sites. I was doing some research last week and I had some serious concerns. I have a test site with almost nothing on it. I used the default search form, nothing customized, and search was taking a looooooong time.Iā€™ve got a ticket into support and theyā€™ve been looking into it. As I test it today itā€™s not too bad, itā€™s about 5 seconds to return results in a basically empty set. I wonder how this would be if I had a set of 1000 or 5000. Any experience with this? Does search set size effect result speed?

Here is the test site. You can take a look if youā€™d like https://ecomtest.trialsite.co/search-test?SearchKeyword=test

Support recommended that I uncheck the ā€œDisable for site searchā€ but that broke things and caused recursion. There was a 4000s pause and then it just kept looping through.

image
image1271Ɨ1544 126 KB

10

Do you mean if we are searching module items, we shouldnā€™t populate the default description field, but only use custom fields?

Maybe thatā€™s the issue here. Iā€™m using the default search form unscoped, so searching for ā€œtestā€ returns all of the test pages Iā€™ve built on this test site.

What if I wanted to search the pages on a site? Or what if I wanted to search news items where the contents is in the description field?

11

What is that syntax? Iā€™ve noticed similar syntax in migrated site, but never really stopped to look into it. There seems to be a secondary module call syntax thatā€™s generated by the migration app. Is there documentation on this anywhere?

12

@Alex_B_Centrifuge I donā€™t think that is what @Adam.Wilson means. Itā€™s about a problem (not only with module but also with site search) I had for a while. To display search results you would usually do something in your list layout like:

<h3><a href="{{this['Url']}}">{{this['Name']}}</a></h3>
<p>{{this['Description'] | strip_html | truncatewords: 20, " [..]"}}</p>

This should actually only render the first 20 words of the pageā€™s content in plain text, but if thereā€™s a liquid module tag within this first 20 words, it will render the module hence spoiling your results.
I found that I can avoid that by using this list layout code:

<h3><a href="{{this['Url']}}">{{this['Name']}}</a></h3>
{% capture maincontent %}{{this['Description']}}{% endcapture %}
{{ maincontent | strip_html | truncatewords: 20, " [..]" }}

This way any possible module tags get rendered BEFORE the html gets stripped and the truncatewords filter applied.

13

Hi @Alex_B_Centrifuge. The searchScope is documented in the ā€œParameters and Optionsā€ table for all components. See here for example:
https://docs.treepl.co/documentation_group/component-types/module-blog-post#secParameters

Basically, itā€™s the same as applying isSearchResult to a component tag but where isSearchResult looks for search parameters in the URL, searchScope instead is coded directly into the component parameter. So it can be hard-coded or dynamically constructed with Liquid variables without the need for passing URL params.