- This topic has 1 reply, 2 voices, and was last updated 6 months ago by
.
-
Posts
-
Hi Ernest, can you explain how taxonomies are searched with ASP? I am getting the results I want with only a few hundred records, but concerned that it may impact the performance when I load my full complement of 47,000 records.
I restricted my index to only three taxonomies as we found earlier that the search performance dropped significantly with more, when I have my 47,000 records loaded. It improves the indexing time slightly, as have I concatenated the 38 CPT fields into a single slug and indexed that. Rather than get ASP to index all 38 CPT fields. This includes the text of 6 taxonomies, the three that were indexed and 3 that were not explicitly indexed. The idea was that text search would be able to search on single keywords out of these unindexed taxonomies without the overhead of filtering by taxonomy. The slight inaccuracy of finding other records with the term in different fields to the specific taxonomy is not an issue.
Out of curiosity, I added the 3 missing taxonomies to Front Search Settings > Categories & Taxonomy Terms. Search settings shows all 6 taxonomies, and terms can be selected in these ‘missing’ taxonomies and filter the search results. This behaviour is exactly what I wanted, but I do not understand quite how it is workking.
I am assuming that for these three ‘missing’ taxonomies, text searches are being performed on the concatenated slug using the terms selected? Unlike the indexed taxonomies that are specfically indexed?
Will doing taxonomy searches this way impact the performance with 47,000 records, as I found when all 6 taxonomies were indexed?
Hi!
It depends. If you have only a plain simple search bar, without any filters, exclusions etc.. then it does not matter at all, you can add as many as you want, it shouldn’t have any noticable effect.
Still it is the best to add only those that are important to for search, to avoid unneccessary extra data.On the other hand, if you are using taxonomy term filters, exclusions etc.., that unfortunately is going to be a lot slower as those queries can’t be indexed (only partially). While filtered queries are very well optimized and are executed in a single request, the database table joins and subqueries can’t be avoided, and those can’t be indexed either. Having more and more records and filtering them is going to affect the performance for sure. There are ways to mitigate that:
– Reducing the number of filters to a minimum
– Using drop-down or radio button based filters – less filter values = less subquery result set = more speed
– Avoiding custom field filters using LIKE queries – those can be painfully slow. Instead using “EXACTLY LIKE” as the operator may have a significant effect on the speed.
- You must be logged in to reply to this topic.