Whenever an editor makes a change to Umbraco content in the backend, the entire cache is dumped. Because of the nature of how our pages are constructed, there is quite a bit of latency involved to bring up a non-cached page. Notably, these are cached macros. My developer tells me that this is by design. Whenever a change is made in the backend, the entire cache is essentially considered dirty and dumped. An entirely new cache is then replaces it in memory.
This renders the server-side cache almost useless because the site is frequently updated. We're not in a position to use a staging server and Courier and we don't think it would work in any case. Courier it has been said does not update the XML cache when it publishes a document to the Production site. We're also a long way from upgrading to Umbraco 7 and implementing load balancing which can improving caching, although it does not do selective caching I am told.
Does anyone have thoughts on how to implement a selective or partial cache that only removes from the cache those pages and associated files that were changed?
We are using the cache which is built into Umbraco, the Macro Cache as well as the cache of partial view (MVC) components. We have created own own disk cache as well, but that really isn't involved here. Unlike 4.11, with 6.26 we are seeing pages load almost instantly when they are cached. However, once any editor makes a change to Umbraco content, the whole cache is dumped. The only way around this is to either create your own caching system or patch Umbraco's code. This behavior is unfortunate and has been criticized by some Umbraco developers. Drupal, on the other hand, allows for changes to the content in the back end w/out obliterating the entire cache. To run a set of macros each time to build a complex pages can take significant time to with a latency of 5-7 seconds. There are caching systems that take advantage of load balancing in Version 7, but we just got on version 6.
Selective Caching of Umbraco on 6.26
Whenever an editor makes a change to Umbraco content in the backend, the entire cache is dumped. Because of the nature of how our pages are constructed, there is quite a bit of latency involved to bring up a non-cached page. Notably, these are cached macros. My developer tells me that this is by design. Whenever a change is made in the backend, the entire cache is essentially considered dirty and dumped. An entirely new cache is then replaces it in memory.
This renders the server-side cache almost useless because the site is frequently updated. We're not in a position to use a staging server and Courier and we don't think it would work in any case. Courier it has been said does not update the XML cache when it publishes a document to the Production site. We're also a long way from upgrading to Umbraco 7 and implementing load balancing which can improving caching, although it does not do selective caching I am told.
Does anyone have thoughts on how to implement a selective or partial cache that only removes from the cache those pages and associated files that were changed?
Hi Richard
Really interesting topic, can you tell more what cache are you using? How pages are rendering?
Thanks,
Alex
Alex,
We are using the cache which is built into Umbraco, the Macro Cache as well as the cache of partial view (MVC) components. We have created own own disk cache as well, but that really isn't involved here. Unlike 4.11, with 6.26 we are seeing pages load almost instantly when they are cached. However, once any editor makes a change to Umbraco content, the whole cache is dumped. The only way around this is to either create your own caching system or patch Umbraco's code. This behavior is unfortunate and has been criticized by some Umbraco developers. Drupal, on the other hand, allows for changes to the content in the back end w/out obliterating the entire cache. To run a set of macros each time to build a complex pages can take significant time to with a latency of 5-7 seconds. There are caching systems that take advantage of load balancing in Version 7, but we just got on version 6.
is working on a reply...