Home › Forums › Product Support Forums › Ajax Search Pro for WordPress Support › Search cache and LiteSpeed webserver
This topic contains 4 replies, has 2 voices, and was last updated by Ernest Marcinko 1 year, 10 months ago.
- AuthorPosts
- May 14, 2021 at 11:51 am #33231
I’m having some speed problems when using filters.
On this site, we have about 5000 ACF posts. Each post has about 250 fields. When a user applies a checkbox filter, it takes about 30 seconds for the result to show up. However, the LiteSpeed server creates a cache, and the next user clicking the same checkbox sees the results in under a second. This is of course great.
But when I change something in the backend, and purge the cache (I have to, or I wont see my change in the frontend) the “filter checkbox” cache is also purged, and the next user will have to wait 30 seconds again, for the cache on that checkbox to be rebuild.
Is there a way to build the cache and not having it purged every time the LiteSpeed server purges it’s cache. Enabling fil-cache option in the plugin does not help. I have also indexed the (custom) fields for the filters, with no effect on the first load/build.
You can try this yourself here: Use the slider to choose a number of guests. If your results show up in a second or so, someone else has already done this and a cache for this number of guests are present. Just choose another number (until you see a load time over 15 seconds). Then reload the page, choose the same number again and you’ll see load times in about 1 sec.
May 14, 2021 at 1:03 pm #33235Hi,
Well, for starters I would suggest making sure you are using the index table engine, it should be a bit faster even when using the filters. I assume the LiteSpeed cache has it’s own object and page cache, which is probably used when doing these searches.
Best,
There is however an internal cache option as well for the plugin, which you can enable here: https://i.imgur.com/hak7iW7.png
This can not be pre-filled, because of the large amount of possibilities, but if you choose a large enough number for the cache interval (I usually suggest 10 days or so – 14400), then it should slowly but surely fill up.
Ernest Marcinko
If you like my products, don't forget to rate them on codecanyon :)
May 14, 2021 at 2:50 pm #33238> index table engine
I’m already using the index table engine and have indexed the helipad field (a checkbox filter option).The plugins own cache is set to database (as you suggest) but it didn’t help (same for database or file). Once the server cache is purged, the frontend load time is back to about 30 sec. for the first user.
I don’t understand why the load times are so high for the filter options, when the options is indexed (see https://worldofsuperyachts.com/wp-content/uploads/2021/05/helipad-slow.jpg )
May 14, 2021 at 2:54 pm #33239You cannot access this content.May 14, 2021 at 3:01 pm #33240Because the search queries are the only parts, which can be indexed fully. Filtering needs to make some table joins – it is not possible to index the combinations – it would lead to exponentially huge database (combination per keyword), probably tens or hundreds of gigabytes for even a couple of thousand products. For 5000 products each with at least 250 fields (and there are probably much more, because of revisions, and WP internal fields etc..), that can grow to a huge table join.
I tried a few combinations, but worst case scenario I was getting ~4.3 second requet times: https://i.imgur.com/Rhs9413.pngTry running an “OPTIMIZE TABLE” command on the wp_postmeta table, to make sure everything is arranged there as well. It sometimes does speed up the queries by a lot.
Best,
Although the 4 second response time seems about realistic to me because of the huge number of fields per post.
Ernest Marcinko
If you like my products, don't forget to rate them on codecanyon :)
- AuthorPosts
You must be logged in to reply to this topic.