Our site search (matrix) takes in excess of 10 seconds to return results if you are a member of the public.
We decided to use the /_performance suffix to check what the exact timings were and blow me down if the site search didn't return results in fewer than 5 seconds. We tried various combinations of posing as a default or public user, with the cache off and set to default and the results were the same every time - site search speed more than twice as quick to return results than if a standard member of the public.
Logging out again though, the search time went back up to in excess of 10 seconds.
We have already set up the search manager to only index certain parts of the site, got a good size noise word list, turned 'contains word' off, vacuumed the database and tried many other tips picked up from the forums and the manuals to speed things up. Reindexed a couple of times as well.
We have turned caching off for our search page to confirm that isn't part of the problem.
We're stumped at the moment. Anyone else experienced this, or can recreate it on their own system?
Our site search (matrix) takes in excess of 10 seconds to return results if you are a member of the public.
We decided to use the /_performance suffix to check what the exact timings were and blow me down if the site search didn't return results in fewer than 5 seconds. We tried various combinations of posing as a default or public user, with the cache off and set to default and the results were the same every time - site search speed more than twice as quick to return results than if a standard member of the public.
Logging out again though, the search time went back up to in excess of 10 seconds.
We have already set up the search manager to only index certain parts of the site, got a good size noise word list, turned 'contains word' off, vacuumed the database and tried many other tips picked up from the forums and the manuals to speed things up. Reindexed a couple of times as well.
We have turned caching off for our search page to confirm that isn't part of the problem.
We're stumped at the moment. Anyone else experienced this, or can recreate it on their own system?
Hi,
There can be many thing that can affect Matrix Search page. Like number of assets returned for search, what are the components on the search is performed, if the sorting is enabled and if it is then on metadata or regular Asset fields.
I have in past seen the sorting can be sometimes an issue if a larger number of assets are returned in the results.
Can you past the output of the performance mode for us to analyse?
Thanks both for your quick responses. We are using a search page asset. Squiz Matrix. 4.8.2.
Number of assets returned for search varies from nothing up to perhaps a hundred or so. We are searching on the main file types and assets (pdf, pages, etc). Sorting is set to relevance, then name and that's it.
Example performance mode output:
Total Time 6.14s, System 0.46s (7%), Queries: 1062
But not logged in, the same query could be 10 seconds +. Of course, I can't provide the performance mode output in that scenario.
Since I posted this topic, we're seeing an improvement in the speed for the public - a couple of days after reindexing and changing the search configuration and also rebooting the matrix. We're optimistic that these improvements will be maintained, but we won't know for another couple of days.
Improvements have not been maintained :( Site search speed is back to well in excess of 10 seconds, frequently 15 seconds or more for a public user. But we're still seeing good search speeds when using the /_performance url suffix.
I've used asset count on the results for both a logged in and a public user and they return the same count each time.
Pagination for the results is off, so all assets are displayed on a single page.
We are printing the asset metadata description field in the search results.
We have type formats set up for different page and file types - I imagine we could rearrange these to reduce the number.
We also have a group level format set up - it groups assets by their type code (pdf files, word documents and so on) - a max of 10 children per group and allows us to display web pages, word documents, pdf files together in the search results.
When you are logged in and testing the search page, are you logged in as a system admin or the root user? They bypass the whole permission checking part of the system and can get greatly reduced page load times for it.
Have you configured the Search Statuses on the Details screen? Filtering out non-Live assets gives the search page less work to do as it doesn't need to see if the current user has write access to non-live assets.
Have you selected to search for Public User content only, and disable the roles and group access checks? These can greatly increase search performance if you are just building a public site search. Again, they remove the need for any permission checking.
Hi - yes, logged in as a system adminstrator, so that would explain the reduced search times. We are only looking for live assets, and have set Public User content only and disabled the roles and group access checks. We've found that clearing the memcache speeds up the site search, then as it fills up, the search slows down again. We have 1gb of memcache. Any recommendations for how much there should be?