I am trying to:
- Do a "multiple checkboxes select" on 3 to more districts on the header banner search section
Link to a page where the issue can be seen:
- hidden link
- hidden link
I expected to see:
- The results of the multiple checkboxes selected in the search result page - those facilities under those selected districts/checkboxes
Instead, I got:
- too long loading time then will have an error "internal server error" and if you try this in a couple of times, it will show an "establish database connection" error
- tried deactivating most plugins, internal server error seems not to show but the results shows a blank/white page instead.
Hi, can I install Query Monitor so we can get a better idea of where the bottleneck is occurring? It's best to run those tests with only Toolset plugins active, then add other plugins incrementally until we can isolate the problem. If we can't do that on the live site, we will need a staging environment set up to match production. Let me know how you would like to proceed.
Thanks Christian - yes that would be fine to install Query Monitor, but only on the dev site copy rather than the live site - we'll get back to you tomorrow with access details.
In the meantime, the client has just alerted me that the live site has hit the DB connection error again, which is unusual - did you try reproducing / causing the error we're reporting in this ticket on the live site at your end within the last 2-3 hours? If so, could you hold off from doing any further testing on the live site please, to avoid it happening again?
Btw Christian can you reopen the secure form?
So I can give you guys the access to our dev site copy
Sure, please provide dev info here. I tested yesterday just before I posted my comment, about 3 hours and 15 mins before you posted your comment asking about it. However, I did not see any database connection errors on the front-end. I saw very long load times and several 524 errors (timeouts).
Okay I see a few things going on here.
1. The featured image shortcode uses "px" in the custom size dimensions. This is actually causing numerous PHP notices in my logs, which is slowing everything down. You should remove the "px" from the custom height and width.
2. Speaking of custom height and width, the more performant method here is to create and register a custom image size in your theme or a custom code snippet. Without getting into too many technical details, the way you have it set up right now with a custom size, width, and height, is going to be unnecessarily slower than using an established, registered size.
3. Even if I fix those things, even if I strip out all the content from the loop except for the post title shortcode, the query still takes over 20 seconds on my machine. That's far beyond what I would consider normal for a search query. Let me ask my 2nd tier supporters for some additional information here. Perhaps there is a more performant way to set up this search, or possibly a better way to structure the data to get the best results. I'll let you know what I find out.
Hi Christian - thanks very much for the help as always!
Have you had any luck getting feedback from the 2nd tier team about the search query performance so far?
At first glance it looks like checkboxes are not be the most performant way to store this data. Instead of individual checkboxes, perhaps individual terms in a custom taxonomy or combination of taxonomies might be more efficient for search queries. From a management standpoint, it might also help to split up your custom fields into multiple field groups. If you have time, we can try to recreate this on a clean installation and make some more solid recommendations. It will take some time.
After more in-depth analysis of your setup and query filters, our lead developer provided some additional feedback. There is not much we can do to improve the performance of the current query based on custom fields. Taxonomy-based queries are more performant than checkbox field queries, especially when there are many options to consider, so the best advice in this situation is to use a combination of taxonomy terms instead of checkbox groups if you want to create more performant custom searches with many optional filters.
I also wanted to mention that, based on your experience and this investigation, our documentation team has added some information to the front-page filters documentation. Possible performance issues with checkboxes using the "OR" condition are noted, along with the recommendation to use taxonomy terms instead:
https://toolset.com/documentation/user-guides/front-page-filters/#vfmh-adding-search-controls
Thanks very much for all the proactive updates on this Christian. We haven't quite got space to work on switching it to the taxonomy yet but we're aiming to get to it soon, and we'll let you know how we got on with it at that point. Let's keep the ticket open for the time being if that would be okay with you?
That's fine. I'll mark the ticket as pending an update from you and you'll get prompted periodically to update the ticket. You can respond with something like "Please keep open" to keep the ticket open. Thanks!
