sql requests from search-filter-pro plugin slowing down site

Trevor

#270480

I am sorry, did removing that form from being live speed that page up? The site may be slow, but I was focussed on the one page. The reason I selected that form was that it was set to search as a Post Type Archive on the post type that was on the home page. That type of search display results method attaches itself automatically to the template for that Post Type’s archive page, whether you actually put the form on the page or not.

Anonymous

#270633

Hi! The homepage became faster immediately after I set the search form to draft. However I noticed later that day, it became slow again. Now it is still slow.

It seems like there is still something requested thousands of post IDs on the homepage (according to query monitor). Any idea what else it could be?

Trevor

#270651

This reply has been marked as private.

Ross Moderator

#270685

This reply has been marked as private.

Anonymous

#270865

This reply has been marked as private.

Ross Moderator

#270940

Hi Wilson

Ok, so from what I can see, this looks roughly correct.

To generate the options in our fields with those dynamic count numbers ( the ( 10 ) you see after every option in a dropdown), we essentially (using our own search tables) grab all the IDs for each field + option

Then we put them into a WP_Query, with a post_type clause, to filter them down to the relevant options.

Believe it or not, we did plenty of testing, and the best performance we could get, to restrict our result IDs to the correct post type, was to have this done at the WP_Query level.

If we didn’t do it there, we would have to do it in our own DB query or via some PHP functions – either way I think this is a necessity.

We are aware though, when the search form is used in places that redirect to results pages (as in your case), this can still be pretty heavy in terms of load (when you are not utilising certain functions).

I have a couple of suggestions going forwards:

1) We have an option – in the wp-admin -> Search & Filter -> Settings -> Use Transients – which reduces the load on some of the queries we carry out when displaying our search form and calculating the counts. Its especially helpful in your scenario ** note – this feature doesn’t work well with multilingual plugins at the moment
2) If you didn’t need it, you could disable auto count – you still might get an ugly query in there somehwere but I think it would significantly increase performance.

In the end, 8000 posts is a fair amount, but I’ve seen S&F running smoothly on a lot more too – so the best thing would be for me to take a look at the slowness / issue in action.

If you can get this up on a staging site somewhere, or if you eventually add those posts back in, then I could do some digging for you and see if you’re hitting any limitations in our plugin or if we can change some settings and improve things further.

Let me know your thoughts.

Best

Anonymous

#271128

Hi Ross,

Thanks for your help. I’ve reuploaded 2500 posts. Can you check the performance now?

Ross Moderator

#271173

This reply has been marked as private.

Anonymous

#271203

Hi Ross. Sorry about that. I’ve extended the access.

Ross Moderator

#271316

Hi Wilson

Apologies for the delay, I’ve now had a look.

You are correct in the slowdown however a couple of things to note:

1) The slow down is mostly visible as admin – caching happens when not logged in – so accessing the site not logged in as admin is a lot quicker – it is expected that difficult queries are slow, and that caching should help with their speed
2) Enabling use transients removed some overhead from the homepage? It went from 8 slow queries, to 3?
https://snipboard.io/gm9XqK.jpg

I’m testing the site now with S&F transients enabled, and not logged in, and I have to say it looks pretty speedy to me?

Happy to do some comparitive tests with you, using something like google page speed insights?

Let me know your thoughts.

Best

[Author]

Posts