Purge only the page on which contains the currently changed product

A

Aklih

Member
#1
#1
Hello,

The problem we are currently facing with is the “Purge”.

What we would like to archive is, when woocommerce-item has changed, purge only:
1. Front page
2. Single Product page
4. Product’s archive pages

Let me clarify for purging only Product’s archive pages. I've also created visual concept - d.jpg, if it helps.

This means to purge only the page on which contains the currently changed product.
So eg. If product with the name “test” is on the shop page number 2, purge only shop page number 2, not all shop pages.Into the product’s archive pages belongs: shop pages, category pages and tag pages.I’ve already had tried option “All pages”, but it will purge all of the pages, which had caused to crash the server. But that is not the case I want to.

To purge front page I can achieve with setting “Front page”, and to purge “Single products page” is set by default setting in woocommerce tab.Is there anyone out there with similar problem, or can help us out?
 

Attachments

A

Aklih

Member
#3
#3
Hi,

well on that I don't have an answer to. On the first hand, I'm thinking that the product data is stored in its cookies.
I understand that this a custom request I'm looking for.

Do you have any suggestions maybe, on my problem?
 
serpent_driver

serpent_driver

Well-Known Member
#6
#6
@Aklih

Regardless of your idea and the fact that this idea was very difficult to implement in LiteSpeed cache plugin, I still want to give you a description of how to solve the problem. As I have already tried to make you understand on LiteSpeed Slack, your problem is that your server is fundamentally overwhelmed with the server load. An alternative solution, which consists in clearing the cache of only certain pages, cannot therefore be the solution. Especially since the plugin cannot know on which pages a certain product is located, in order to only purge the cache of this page. While the idea would be good, it would result in code overhead. The solution must therefore look different, even though this solution solves your problem directly.

The point is that if you have a large number of URLs, it is simply impossible to warm up the cache of all those URLs. Less for performance reasons, but for reasons of time. Even though my custom cache crawler can do everything much faster than the built-in crawler of the LiteSpeed Cache plugin for WP, the Kitt Cache Crawler is bound to physics. This means that the crawl speed can only be as fast as the server allows.

My idea of how to solve the problem with a (too) high number of URLs to be crawled takes a completely different approach. Not all URLs of a website are the target, but only the URLs that are called up the most.

So why warm up the cache of URLs when those URLs are accessed very rarely?

If you now follow this thesis, the number of URLs and their cache would be reduced dramatically. Significantly fewer URLs whose cache must be whyuped inevitably means that cached URLs are available much faster. Especially since it's ultimately just about loading the "most wanted" URLs quickly.

I have already implemented this idea in my Kitt Cache Crawler and it will soon be available for free download.
 
Last edited:
R

Rose Cooper

New Member
#7
#7
To achieve the specific purging behavior you described, you will likely need to use a caching plugin or service that allows for fine-grained control over which pages are purged when specific actions, such as updating a product, occur. One example of such a plugin is the "Cache Enabler" plugin. It allows you to manually specify which pages to purge when certain actions happen on your website.

Additionally, there are other third party caching service providers like Cloudflare and Fastly that offers fine grained cache purging. You may also want to consult with a developer or a systems administrator to properly configure the caching and purging settings on your website to ensure that it is optimized for performance while also meeting your specific requirements.
 
P

peta.dol

Member
#9
#9
serpent_driver said:
@Aklih

Regardless of your idea and the fact that this idea was very difficult to implement in LiteSpeed cache plugin, I still want to give you a description of how to solve the problem. As I have already tried to make you understand on LiteSpeed Slack, your problem is that your server is fundamentally overwhelmed with the server load. An alternative solution, which consists in clearing the cache of only certain pages, cannot therefore be the solution. Especially since the plugin cannot know on which pages a certain product is located, in order to only purge the cache of this page. While the idea would be good, it would result in code overhead. The solution must therefore look different, even though this solution solves your problem directly.

The point is that if you have a large number of URLs, it is simply impossible to warm up the cache of all those URLs. Less for performance reasons, but for reasons of time. Even though my custom cache crawler can do everything much faster than the built-in crawler of the LiteSpeed Cache plugin for WP, the Kitt Cache Crawler is bound to physics. This means that the crawl speed can only be as fast as the server allows.

My idea of how to solve the problem with a (too) high number of URLs to be crawled takes a completely different approach. Not all URLs of a website are the target, but only the URLs that are called up the most.

So why warm up the cache of URLs when those URLs are accessed very rarely?

If you now follow this thesis, the number of URLs and their cache would be reduced dramatically. Significantly fewer URLs whose cache must be whyuped inevitably means that cached URLs are available much faster. Especially since it's ultimately just about loading the "most wanted" URLs quickly.

I have already implemented this idea in my Kitt Cache Crawler and it will soon be available for free download.
Click to expand...
Hello do you plan also make this crawler for Joomla? Thank you
 
A

Aklih

Member
#11
#11
@serpent_driver Thanks for your answer and patience. Sorry for the long delay with my response.

Therfore, I understand, that its not impossible to achieve what i'm trying to achieve, but could/would make code overload and make things even worse.

I have 2 questions left about the crawler:

01
How does currently crawler works then? In which sequence does he crawl through the pages (on which pages does he starts and ends)?

02
Is your "Kitt Cache Crawler" an add on for LS? Or is a separate plugin for WP?

Best regards!
 
serpent_driver

serpent_driver

Well-Known Member
#12
#12
Aklih said:
Therfore, I understand, that its not impossible to achieve what i'm trying to achieve, but could/would make code overload and make things even worse.
Click to expand...
You got that right!

Aklih said:
How does currently crawler works then? In which sequence does he crawl through the pages (on which pages does he starts and ends)?
Click to expand...
Which one do you mean? The built-in crawler from cache plugin or mine, the Kitt Cache Crawler?

Aklih said:
Is your "Kitt Cache Crawler" an add on for LS? Or is a separate plugin for WP?
Click to expand...
It's a standalone application that runs parallel, but independently from WP, but optimized for the needs of LiteSpeed web server and LScache, so it is not a universal crawler. Each Kitt crawler version is made for a certain application. This and much more makes it x-times faster and causes only half the load. So there is a good reason why it is not a plugin. A plugin and its possibilities are limited by the adversities, especially with Wordpress.
 
A

Aklih

Member
#13
#13
01
Which one do you mean? The built-in crawler from cache plugin or mine, the Kitt Cache Crawler?

Sorry, I meant the built-in crawler in LS cache.

02
It's a standalone application that runs parallel, but independently from WP, but optimized for the needs of LiteSpeed web server and LScache, so it is not a universal crawler. Each Kitt crawler version is made for a certain application. This and much more makes it x-times faster and causes only half the load. So there is a good reason why it is not a plugin. A plugin and its possibilities are limited by the adversities, especially with Wordpress.[/QUOTE]

Ok, so you are offering a service, that runs on website. It's optimized and customized for the needs of the website, that will run on, right?
 
serpent_driver

serpent_driver

Well-Known Member
#14
#14
Aklih said:
Sorry, I meant the built-in crawler in LS cache.
Click to expand...
The built-in crawler crawls the URLs from the sitemap and in the order they are listed in it. If you have activated webp replacement, mobile view or|and guest mode, each "Cache Profile" will be crawled or used individually.

Aklih said:
Ok, so you are offering a service, that runs on website.
Click to expand...
No, it is not a service. It's an application that has to be installed on your server. With this application you can do your own service. ;)

Aklih said:
It's optimized and customized for the needs of the website, that will run on, right?
Click to expand...
It is optimized and customized for the application you have installed, for LiteSpeed web server, LScache and the LScache cache plugin, but not for the website. Why for the website?
 
A

Aklih

Member
#15
#15
01
The built-in crawler crawls the URLs from the sitemap and in the order they are listed in it. If you have activated webp replacement, mobile view or|and guest mode, each "Cache Profile" will be crawled or used individually.

Thanks a lot for an explanation, it makes sense yeah.

02
It is optimized and customized for the application you have installed, for LiteSpeed web server, LScache and the LScache cache plugin, but not for the website. Why for the website?

Sorry I haven't made myself clear. With website I meant LS webserver.
So It's already production ready right? And I can find it here.

Thanks a lot for your time and help!
 
serpent_driver

serpent_driver

Well-Known Member
#17
#17
Aklih said:
Thanks a lot for an explanation, it makes sense yeah.
Click to expand...
You can also do it differently, because the order of the URLs in the sitemap doesn't follow any real logic. We are planning a better solution, some of which I have already described above. However, this solution is only part of a larger solution.
 
You must log in or register to reply here.
Top