Revolution | Cache Browser-Manager/ Selective Cache Clearance

Came up with a thought..

As i understand, by default cache of a resources/json set to be 0 which means it won’t expire until we clear the cache,
it saves time on processing and unnecessary queries ,easing up on server load.

it’s great and all but what if suppose we have lots of resources cached and we need to modify & adjsut one or several resources, for the change to take place we need to check the box for clearing the cache (BTW it’s set to clear the cache on save by default),
then we lose all the cache we kept so far (am i right?) and we need to generate it over again even though we made a small change in only a certain resource/s.

What if.. we had the possibility to choose? (haha.. catchy phrase)
Maybe adding an option of excluding/including specific resources/elements from been cleared from the cache by selection of a cache-policy or CCL(Cache-Clearance-List) or something.
Or maybe use a batcher/cache manager/browser? instead of always just get rid of all site’s cache dumping all the effort who’s been made to enhance site’s speed.

This is just an idea caught up in my mind, i might misunderstand the cache system a bit, so tell me if it has some sense in it?.
What do you think?


- - - - - - - - - - -

Another thought:
What about adding plugged-in ability of running caching-corn-job for the purpose of serving content faster, letting the server to do all that hard work processing at backstage by itself preparing to serve ready-content (only for initial-havy-load-pages)?

The idea looks nice at a first glance... but if all you change is a pagetitle of one resource, yet it is mentioned using Wayfinder (or getResources, or ...) on any of the other pages... you’ll be facing old data.

I think that if you have a lot of resources, you’ll generally also have a lot of people viewing them (hopefully) and on the first view it will be cached again - leaving only the first person viewing a resource wait a little longer (but still, depending on the content, snippets and plugins of course) not amazingly long.


So I’m not really in favour of this, sorry.

But it’s good to think about all the options anyway.

I have had the idea for some time now of adding an advanced button next to the clear cache checkbox of Resources for allowing more granular control of cache clearing. I consider this a very important topic, as when working on high-load sites and trying to frequently update small elements of content targeted to specific pages, you can run into some major bottlenecks precisely because the entire cache is being cleared. I would love to see dialog exploring ideas on how to present such options in a the UI. There is a lot of granularity and extensibility in the caching system and figuring out how to present all of the various caching options in an intuitive and functional way is the challenge.

Quote from: Mark at Jan 02, 2011, 09:46 PM

The idea looks nice at a first glance...
but if all you change is a pagetitle of one resource, yet it is mentioned using Wayfinder (or getResources, or ...) on any of the other pages... you’ll be facing old data.

That’s why i suggested adding an option of excluding/including specific elements from been cleared from the cache by selection of a cache-policy or CCL(Cache-Clearance-List) or something. Or maybe use a batcher/cache manager/browser to be more specific,
That way you can clear cache to associated resources/elements as well (maybe it’s even a good idea to implant a system to keep track of the cache-links between the different resources/elements).
Maybe it sound’s like an headache, but i think it’s important to think about that.

Quote from: Mark at Jan 02, 2011, 09:46 PM

I think that if you have a lot of resources, you’ll generally also have a lot of people viewing them (hopefully) and on the first view it will be cached again
- leaving only the first person viewing a resource wait a little longer
(but still, depending on the content, snippets and plugins of course) not amazingly long.

You’re forgetting also the server load and the CPU usage raising to high levels.
But as concerned to the users, This first user/(customer?) that is waiting a little bit longer might leave the site because of the slow load.
So this is a major UX node for users, the speed issue.

here’s an article about this issue:
http://trentwalton.com/2010/08/24/dont-make-me-wait/

I guess things like server load, cpu usage and also the increased loading times depend on the type of website.

Most websites I’ve created for smaller companies consist of a small number of pages (say 25 max) with Wayfinder, here and there a getResourceField when needed and perhaps a breadcrumb.


Every milliseconds count, I can agree to that, but on sites like what I said it wont make much of a difference imo.


If you do have a site with more dynamic then static contents it may be convenient.



I think I may do a test some time to compare cached vs uncached, I’ve never really noticed a difference in loading time after clearing cache myself, so maybe I’m underestimating this.

Quote from: gOmp at Jan 08, 2011, 01:23 PM

That’s why i suggested adding an option of excluding/including specific elements from been cleared from the cache by selection of a cache-policy or CCL(Cache-Clearance-List) or something. Or maybe use a batcher/cache manager/browser to be more specific,
That way you can clear cache to associated resources/elements as well (maybe it’s even a good idea to implant a system to keep track of the cache-links between the different resources/elements).
Maybe it sound’s like an headache, but i think it’s important to think about that.

A list of including specific Elements (or Resources) is already a problem. If you have thousands of them, how do you present that in a usable way? And yes, I am not even going to think about the suggestion regarding tracking relationships between Resources/Elements because I need to use my brain today for other things—I truly believe that would be a fool’s errand.

Quote from: gOmp at Jan 08, 2011, 01:23 PM

You’re forgetting also the server load and the CPU usage raising to high levels.
But as concerned to the users, This first user/(customer?) that is waiting a little bit longer might leave the site because of the slow load.
So this is a major UX node for users, the speed issue.

here’s an article about this issue:
http://trentwalton.com/2010/08/24/dont-make-me-wait/

There’s always a tradeoff between serving things as fast as possible and dynamically presenting changing content based on contextual information about the client doing the browsing (time, browser engine, language, identity, etc.). We can certainly optimize specific things, but I don’t really think this argument has much weight in the custom cache clearing debate. There are simply too many factors, and unless you are serving 1000’s of requests per second, I would make sure everything, even when not cached was running as efficiently as possible. There are also times when performance requirements would likely exclude the use of any kind of generic content management system, or even dynamically-served pages at all (i.e. static files with changes being manually published).

Quote from: OpenGeek at Jan 10, 2011, 11:51 AM

Quote from: gOmp at Jan 08, 2011, 01:23 PM

..excluding/including specific elements from been cleared from the cache by selection of a cache-policy or CCL(Cache-Clearance-List) Or maybe use a batcher/cache manager/browser to be more specific, That way you can clear cache to associated resources/elements as well (maybe it’s even a good idea to implant a system to keep track of the cache-links between the different resources/elements).

A list of including specific Elements (or Resources) is already a problem. If you have thousands of them, how do you present that in a usable way? And yes, I am not even going to think about the suggestion regarding tracking relationships between Resources/Elements because I need to use my brain today for other things—I truly believe that would be a fool’s errand.

You probably right about the bond-tracking, it really can be a mind blower and some sort of chasing your tail in large scale sites (or those with enormous amount of elements).
What is the approach to this matter in other large scale content management systems?
I’m really not that much of a programmer to evaluate how, but still, i think that balancing a bit the cache would be great.
Even I’m not that expert it seems that ’doing laundry to all the clothes in the closet after using one t-shirt’ it’s a little bit off it’s purpose.


Another thought:
Maybe it’s would be more reasonable to give us the ability to make independent-small-cache-zones assigned to templates(for example) and when we clear the cache we would choose which zones to clear or clear it all by choice.

Quote from: OpenGeek at Jan 10, 2011, 11:51 AM

Quote from: gOmp at Jan 08, 2011, 01:23 PM

..the speed issue.

There’s always a tradeoff between serving things as fast as possible and dynamically presenting changing content based on contextual information about the client doing the browsing (time, browser engine, language, identity, etc.).
We can certainly optimize specific things, but I don’t really think this argument has much weight in the custom cache clearing debate.
There are simply too many factors, and unless you are serving 1000’s of requests per second,
I would make sure everything, even when not cached was running as efficiently as possible. There are also times when performance requirements would likely exclude the use of any kind of generic content management system, or even dynamically-served pages at all (i.e. static files with changes being manually published).

agreed.



Once again, I must ask..
Even with cache.. on dynamic-heavy-pages the initial load is taking a while. why not considering to sweep this initial load from the user by assigning a Cron-job?
I was in a need of scrapper and i made something like this for that need.

Maybe those pages are a few not worth implanting a special code for them in the core.
A well designed page (by programing) should’nt load that much time, so probably when it take ages to load, you do it wrong, right?

I completely agree that some sort of control of selective caching would be really nice to have. Yes, you can try to optimize the performance of pages uncached, but the whole point of caching is that it improves performance. It’s a shame to sacrifice that boost for the entire site just to edit one page.

I can see how deciding which pages to clear could be difficult in some situations, but for a simple heirarchical structure it should be sufficient in most cases to clear the cache for siblings and ancestors only, leaving the rest of the site untouched. That would work fine for me, and if every now and then there is a crosslink or something and somebody sees old data, that’s a sacrifice I’d be willing to make to keep the performance boost. You would just have to remember to clear the whole cache every now and then to clean up any loose ends.

The challenge is that if you change any attribute of a Resource which affects a cached menu Snippet (or any other Snippet for that matter) in another Resource anywhere in the site structure, and you don’t clear the entire cache, your menus are cached incorrectly. Again, we definitely need the ability to clear just a particular Resource’s cache file( s ), but the default behavior definitely needs to clear the entire site cache (or at least for a particular Context). If we can identify changes that would affect menus or links or other things that should clear the entire cache, or specific parts of it, then perhaps we can control the default behavior with finer granularity, but I think this is going to get complex quickly.

As for UX, I’m currently leaning toward just having an advanced cache clearing dialog that users can optionally enable when saving changes to Resources, Elements, or potentially any objects in the manager, but am not convinced this extra step when hitting save is the best approach; maybe just letting users manually open the advanced panel before saving is a better approach.

I also think we need to consider a way to queue a set of changes together before the caches are cleared—there are often times I make a lot of small edits to a number of Resources, and it would be nice to be able to delay the cache clear until I am done with all of them. A reminder that I have changes outstanding but have not cleared the cache could be generated from this queue.

at least for a particular Context

Can you clear the cache for only one context now? That would be really useful for multi-domain installs.